Log file Viewer

[06:50:41] <wiggy> dstufft: is there any documentation for manylinux? I see it mentioned in places now, but I don't remember seeing an announcement for it

[06:51:53] <tdsmith> there's a reasonable pep: https://www.python.org/dev/peps/pep-0513/

[06:53:53] <wiggy> the manylinux example seems to violate the PEP by installing atlas, which the PEP does not allow

[07:49:48] <apollo13> wiggy: how so?

[07:50:27] <wiggy> apollo13: atlas is not in the list of things you are allowed to link with

[07:50:56] <apollo13> https://travis-ci.org/pypa/python-manylinux-demo/jobs/139930636#L358

[07:50:59] <apollo13> it embeds

[07:51:38] <wiggy> ahm, hm

[07:51:42] <wiggy> somehow that feels risky

[07:52:59] <wiggy> I can see risk of two wheels embedding different versions of the same lib

[07:53:08] <apollo13> sure, but how else would it work

[07:53:17] <apollo13> you can obviously make another wheel for the lib itself

[07:53:19] <wiggy> it wouldn't

[07:53:40] <wiggy> manylinux feels like a "lets hope it works but no guarantees" thing to me

[07:53:53] <wiggy> which is perfectly fine and it'll work for >95% of wheels

[07:54:13] <wiggy> and it'll be a bitch to debug when it breaks

[09:38:51] <apollo13> wiggy: well, kinda, but what are the alternatives

[09:39:10] <wiggy> os-release specific wheels

[09:39:18] <apollo13> well, you can upload those too

[09:39:26] <apollo13> I think, or at least you can use them

[09:39:27] <wiggy> they don't even exist atm

[09:39:43] <wiggy> afaik the tooling to create those doesn't exist yet

[09:39:47] <apollo13> ?

[09:39:54] <apollo13> sure, just run bdist_wheel

[09:40:02] <apollo13> uploading is also supported since dstufft enabled manylinux iirc

[09:40:23] <wiggy> I mean non-manylinux linux wheels

[09:40:33] <apollo13> yes

[09:40:36] <wiggy> I have lots of linux-wheels in a private repo

[09:40:41] <wiggy> but they are not tagged with OS release

[09:40:53] <wiggy> so I have separate registries for each OS version

[09:40:56] <wiggy> very annoying to do

[09:41:00] <apollo13> ah yes, the name is still linux

[09:41:32] <apollo13> but if you compile those on centos 5 they probably work everywhere (assuming stable librariers)

[09:41:38] <apollo13> if not it is annoying anyways

[09:41:56] <apollo13> not sure how far the tagging for os specific stuff is

[09:42:29] <wiggy> there is no way my stuff will compile on centos 5

[09:43:23] <wiggy> I need a fairly decent c++11 compiler, recentish boost version, etc.

[09:44:05] <apollo13> mhm, what is stopping you from compiling those on centos5?

[09:44:58] <wiggy> the fact I have better things to do with my life

[09:45:12] <wiggy> I'm not going to backport tons of dependencies just so I can use manylinux

[10:29:06] <count> hello

[10:29:31] <count> guys, no ... who change the pypi endpoint to force? you've broken a few thousand Puppet nodes.

[10:29:35] <count> test:

[10:29:35] <count> curl -v -X POST http://pypi.python.org/pypi -H 'Content-type: text/xml' -d "<?xml version='1.0'?><methodCall><methodName>package_releases</methodName><params><param><value><string>pip</string></value></param></params></methodCall>"

[10:30:06] <count> that's basically what Puppet does internally until the very latest version (which noone will be using yet, and people can't be expected to update to)

[10:30:16] <count> please revert that forcing of HTTPS ASAP

[10:33:29] <count> fixing commit on Puppet side: https://github.com/puppetlabs/puppet/commit/152299cc859fc74343c697841848086d4e41b6f8

[10:33:59] <count> related issue there: https://tickets.puppetlabs.com/browse/PUP-6120

[10:34:14] <count> how can I repots this correctly?

[10:34:22] <count> s/repots/report/?

[10:36:48] <count> ... uh: this is about the change of the pypi endpoint to force HTTPS.

[11:44:34] <wiggy> count: report that to the distutils-sig mailinglist

[11:47:07] <wiggy> count: the change was announced there as well: https://mail.python.org/pipermail/distutils-sig/2016-June/029125.html

[12:00:01] <count> wiggy: thanks!

[12:05:26] <count> someone subscribed to that mailing list and seeing my message there just now? I've send it via a webinterface, which might not have worked

[12:16:20] <wiggy> doesn'st seem to have worked looking at the list archive

[12:40:05] <count> wiggy: hrmbl. wonder how I can get the full headers for a proper threaded reply

[12:40:27] <wiggy> I don't know

[15:18:41] <papamoose> Anyone got any news concerning this: https://github.com/pypa/pip/issues/3776 I am super close to building my own .deb package... :(

[15:20:31] <tdsmith> papamoose: that ticket suggests that the correct version of pip is actually installed and the message saying otherwise is lying

[15:20:31] <tdsmith> is that a problem for you?

[15:24:30] <papamoose> tdsmith: http://pastebin.com/raw/VjxT7fjW

[15:25:20] <tdsmith> it seems you have too many pips

[15:26:14] <papamoose> my concern is the behavior change. The system pip version could be what it was, and I could install a more up to date version over in /usr/local. $PATH would ensure that the version in /usr/local would be the default.

[15:26:19] <tdsmith> for bonus points: python -c "import pip; print(pip.__file__, pip.__version__)"

[15:26:58] <tdsmith> $PATH won't help you here; the wheel scripts just `import pip`

[15:27:14] <tdsmith> so ultimately sys.path is controlling

[15:27:26] <papamoose> that does return: 8.1.2.

[15:32:37] <papamoose> Another paste: http://pastebin.com/raw/0HFU8XuK I can't be the only one that thinks this is nuts...

[15:34:03] <count> ubuntu? nuts? completely agree.

[15:34:40] <papamoose> count: :P

[15:35:13] <count> wiggy: seems to have made it - https://mail.python.org/pipermail/distutils-sig/2016-June/029153.html

[15:35:45] <tdsmith> i mean, it's not so bad: you have pip installed to multiple locations in sys.path. you have a few different scripts named `pip` in different locations which will all have the same behavior, which is to load the first pip in sys.path

[15:37:05] <papamoose> I was under the impression sys.path would load the one in /usr/local first

[15:38:02] <count> aaah, where would be the fun in that

[15:38:27] <tdsmith> well python -c 'import pprint as pp; import sys; pp.pprint(sys.path)' should settle that

[15:43:12] <papamoose> tdsmith: that does what you say it does, and explains the issue in my paste.

[21:11:25] <Vako> folks im typying this pip install sqlalchemy bson

[21:11:36] <Vako> and getting this error

[21:11:47] <Vako> Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-NKpIkE/bson/

[21:11:53] <Vako> any clues?

[21:13:54] <Vako> ?

[21:18:14] <Vako> hello?

[21:23:54] <[Tritium]> Vako: is there anything in the log?

[21:29:59] <njs> hmm, if wiggy comes back, someone should point out to them that the manylinux docker image supports C++11 and that the way auditwheel vendors libraries is very careful to make sure that everything still works even if two diferent wheels embed different versions of the same lib :-)

[21:30:35] <njs> also, is anyone running Ubuntu 16.04?

[21:31:30] <njs> there is a proposed backport to (finally) fix the issue where the default $PATH is incompatible with "pip install --user", but it needs someone to check the "I tested this and it worked" button before the backport goes through:

[21:31:31] <njs> https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1588562/comments/4

[21:39:56] <[Tritium]> When did 'Requires Distributions' get added to pypi?