pmxbot IRC Log Viewer

[08:19:30] <spaceSub> I know I asked this before, but I can't get it done. I have a wheezy with python 3.2. I used pip to install virtualenv with pip-3.2. In my virtualenv I also have an pytjon 3.2 now. Can I upgrade to//install python 3.4? Can you walk me through?

[08:25:15] <spaceSub> I expected I could just make pip install it, but 'pip install python==3.4' does not find it.

[08:25:35] <mgedmin> no, pip cannot install a python for you

[08:26:36] <mgedmin> you'll need to find a Debian repository with python 3.4 (maybe use packages from jessie) or something like https://github.com/yyuu/pyenv

[08:27:50] <spaceSub> Hmm, okay. too bad.

[08:29:16] <spaceSub> Okay, another one. Does pypi packages have metainformation about what the oldest python version is, they work with? Is there an option for pip install to only install compatible stuff?

[08:30:50] <mgedmin> yes and no

[08:33:49] <spaceSub> Alright, thanks. :)

[08:37:53] <mgedmin> to clarify, packages can declare supported python versions, e.g. see "Programming Language :: Python :: x.y" in https://pypi.python.org/pypi/objgraph

[08:38:05] <mgedmin> but pip at the moment goes for the latest version always

[08:38:27] <mgedmin> you have to manually specify constraints if a package X dropped support for the version you're on

[08:41:22] <mgedmin> hm, I thought there might be a bug open about pip downloading incompatible packages, but I can't find one at https://github.com/pypa/pip/issues

[08:41:48] <mgedmin> oh well, the current HTTP API that pip install uses doesn't expose that information anyway

[08:42:38] <apollo13> it's just metadata, the only thing pip can care about is the filename

[08:42:43] <apollo13> (for now)

[08:43:30] <spaceSub> Yeah, I figgured. I am stuck on wheezy and need to work with ipaddresses. I used the ipaddress module in 2.7 before, but that was ported and merged into 3.3 so I can't use that. Then I tried ipaddr but that also has only versions on pypi compatible with 3.3 or 2.X. What a paint in the bum.

[08:44:27] <spaceSub> I think I might just go with getting python 3.4 from somewhere..

[08:45:28] <spaceSub> s/paint/pain

[09:06:20] <doismellburning> spaceSub: alas Wheezy Backports doesn't ship with python 3.4

[09:07:34] <spaceSub> Yeah, alas indeed.

[09:11:53] <spaceSub> Bleh, this sucks shit through ten bricks.

[12:49:50] <flupke> Hi, I can't build wheels for unittest2 since 0.6.0, because of a weird bug related to the way they define the version number (it's a custom class with __str__ now...), anyone found a workaround?

[12:50:58] <flupke> I see wheels for unittest2 on pypi, but I don't know how to build it myself

[12:52:22] <flupke> Oh, just have to add a sdist before bdist_wheel... (found in their Makefile)

[12:52:39] <mgedmin> really? that's interesting

[12:53:33] <flupke> sdist must convert version to str somewhere in the process

[12:55:07] <mgedmin> I'd call that a bug in the package's setup.py

[12:55:19] <mgedmin> e.g. if you do 'pip wheel unittest2', will that work?

[12:55:35] <mgedmin> (for me it downloads the wheel from pypi and does nothing, so it works for some values of work...)

[12:57:08] <flupke> you see the error in question if you do "pip wheel unittest2 --wheel-dir . --no-use-wheel"

[12:57:27] <flupke> (without --no-use-wheel it just downloads the wheel)

[12:58:08] <mgedmin> AttributeError: wheel_dist_name

[12:58:19] <flupke> I agree this is a bug in distutils2, their version class is really WTFy

[12:58:50] <flupke> https://hg.python.org/unittest2/file/95d2c7867857/setup.py => late_version

[12:59:58] <flupke> in unittest2*

[13:00:09] <mgedmin> oh dear why? why do that?

[13:01:00] <mgedmin> not that I haven't done Bad Things in setup.py's myself *cough* https://github.com/mgedmin/zodbbrowser/blob/master/setup.py#L17

[13:08:52] <flupke> Now I have to figure out how to do this with pip...

[13:16:46] <flupke> Also pip does not set its return code to nonzero when setup.py fails

[13:20:15] <DanielHolth> doesn't the git version of pip do that by now?

[13:50:11] <flupke> In case you're wondering why I bother building wheels for packages that already offer wheels, this is for my requirements freezing tool: https://github.com/Stupeflix/freeze-requirements

[14:33:28] <cdunklau> hola, i'm trying to figure out what the right solution to #2091 would be...

[14:35:02] <cdunklau> dstufft appears to have added the IncompleteRead import to deal with a content-encoding thing... but requests doesn't have IncompleteRead imported in requests.compat anymore

[14:35:12] <cdunklau> https://github.com/pypa/pip/blame/1.5.6/pip/download.py#L416

[14:40:17] <cdunklau> oooooh i hate debian sometimes

[14:47:29] <mgedmin> what did debian do to you?

[14:47:37] <cdunklau> mgedmin: https://github.com/pypa/pip/issues/2091

[14:48:22] <mgedmin> well, that's a pretty clear debian bug

[14:48:38] <cdunklau> mgedmin: basically, pip broke with the importerror described after i upgraded. because i had requests 2.4.3 installed in the user site

[14:48:52] <mgedmin> looks like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744145

[14:50:17] <mgedmin> so debian's requests 2.4.3 is patched to provide that compat import

[14:50:26] <mgedmin> but you had a genuine upstream requests in your virtualenv?

[14:50:55] <cdunklau> mgedmin: i had a genuine upstream requests in the user site

[14:51:09] <mgedmin> fun

[14:54:18] <mgedmin> somebody should tell the Debian people about this use-case

[14:54:38] <mgedmin> if I understand correctly, doing a pip install --user requests will break the system-wide pip?

[14:54:44] <mgedmin> or is it just virtualenvs that are affected?

[14:55:27] <cdunklau> mgedmin: oddly enough a virtualenv worked fine

[14:59:53] <mgedmin> can you figure out how to reproduce this?

[15:00:19] <cdunklau> mgedmin: https://bpaste.net/show/590a93f96d76

[15:00:45] <cdunklau> i don't really get why the venv's python won't let me import the requests wheel

[15:01:39] <mgedmin> wheels aren't meant to be directly importable

[15:01:44] <cdunklau> oooh

[15:01:49] <mgedmin> why do you even have a python-wheels/ dir in the venv?

[15:02:19] <mgedmin> I've never seen one before

[15:02:19] <cdunklau> mgedmin: no clue. that's just how it was created

[15:02:24] <mgedmin> maybe debian patches virtualenv?

[15:02:28] <cdunklau> mgedmin: 1.11.6

[15:02:32] <mgedmin> (well of course they do :)

[15:02:43] <cdunklau> that's my virtualenv version. yeah probably yet another debian thing

[15:03:02] <mgedmin> anyway, your paste has no errors (other than the error of importing requests before you pip install it, which is expected, I'd say)

[15:04:38] <cdunklau> mgedmin: right, i'm just trying to reason why the virtualenv's pip works after installing requests 2.4.3

[15:05:53] <mgedmin> peek inside the venv, see if its lib/pythonX.Y/site-packages/pip has a vendored requests?

[15:06:22] <cdunklau> it does not

[15:07:51] <cdunklau> and that's expected, since virtualenv just copies pip from the system

[15:08:14] <mgedmin> where does it find requests then?

[15:12:30] <cdunklau> mgedmin: notice in the paste i can't import requests from inside the virtualenv until i manually install it

[15:12:50] <mgedmin> I did

[15:17:53] <cdunklau> mgedmin: so somehow the virtualenv's pip is importing requests 2.3.0 /home/cdunklau/venv/lib/python-wheels/requests-2.3.0-py2.py3-none-any.whl/requests/__init__.py

[15:18:10] <cdunklau> i'm very confused

[15:18:30] <mgedmin> perhaps debian's patched pip adds the .whl to sys.path directly

[15:18:49] <mgedmin> wheels are zip files; python can import (python-only) stuff from them -- if you add each .whl into sys.path

[15:19:26] <mgedmin> they're not meant to be used that way (in the sense that things like C extension modules or python code that uses os.path.dirname(__file__) to locate data files will break)

[15:19:31] <mgedmin> but some wheels can be used that way

[15:23:53] <cdunklau> aaaaaaaaaaaaaaaaaaaaaaa

[15:23:55] <cdunklau> mgedmin: https://bpaste.net/show/4679f2a11ea6

[15:23:57] <cdunklau> you're spot on

[15:25:11] <mgedmin> ok, now we understand what's happening

[15:25:17] <mgedmin> is there still a problem?

[15:25:33] <cdunklau> mgedmin: oh i hope you weren't doing this assuming i had a problem

[15:25:35] <cdunklau> mgedmin: :(

[15:26:23] <cdunklau> mgedmin: your guidance certainly helped me understand why the virtualenv worked right, though. Thanks a bunch

[15:26:28] <mgedmin> ah, it wasn't you who had the problem!

[15:26:35] <cdunklau> mgedmin: yeah sorry :(

[15:26:39] <mgedmin> np

[15:27:09] <mgedmin> if the original reported did something like 'sudo pip3 install -U requests', well

[15:27:15] <cdunklau> mgedmin: now i just know to not trust debian. because they apparently only did that to support virtualenvs, and didn't know/care about the user site: https://bpaste.net/show/3c39ed2e718a

[15:27:33] <mgedmin> you keep talking about the user site, and I don't understand how it enters the picture

[15:27:48] <mgedmin> a-ha! thank you

[15:28:08] <mgedmin> if I used Debian, I'd file a debian bug about this

[15:28:13] <cdunklau> it _still_ breaks when requests is installed in the user site, so apparently the sys.path hacks to get the wheel it wants available don't happen when it's running outside of virtualenv

[15:28:17] <mgedmin> right

[15:28:25] <mgedmin> something like that

[15:28:41] <mgedmin> debian patches pip, the patch causes breakage when you pip install --user requests; ergo debian should fix their patch

[15:28:46] <mgedmin> or so it seems to me

[15:28:54] <cdunklau> agreed

[15:29:02] <mgedmin> dunno if that should be a new debian bug or if https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744145 can be reused for this

[15:29:10] <cdunklau> at no point did i believe this was pypa's problem :)

[15:29:11] <mgedmin> well, merging bugs is simpler than splitting them, I suppose

[15:29:30] <cdunklau> ok at first i did. but then i saw you guys do the vendoring thing

[15:29:50] <mgedmin> *just a curious user that likes debugging a lot*

[15:29:52] <cdunklau> well, pip's problem or whatever

[15:30:04] <cdunklau> mgedmin: heh, a man/woman/other after my own heart

[15:30:23] <cdunklau> hm. i suppose i should just say person. oh well

[15:30:27] <mgedmin> it seems rather broken that installing stuff into ~/.local can break system-wide stuff

[15:30:34] <mgedmin> +1 for gender-neutral language

[15:30:45] <cdunklau> well it only breaks stuff for that use, not system-wide

[15:30:49] <cdunklau> s/use/user/

[15:30:55] <mgedmin> right, but it shouldn't

[15:31:07] <mgedmin> isn't that why debian invented /usr/lib/pythonX.Y/dist-packages?

[15:31:25] <cdunklau> mgedmin: well, the only reason it wouldn't normally with pip is because of the vendoring

[15:33:06] <cdunklau> i really should file a bug against this. but i have too much hate in my heart at the moment

[15:33:10] <cdunklau> maybe I'll do it later

[15:33:24] <cdunklau> mgedmin: anyway, thanks again :)

[15:34:16] <cdunklau> mgedmin: sure, sure, i understand why debian would disallow vendored packages

[15:34:24] <mgedmin> "let's not have multiple copies of the same library" sounds like a principle I can get behind -- iff you also take care to manage version incompatibilities across the whole archive

[15:35:02] <mgedmin> so I never tried pip install --user

[15:35:17] <mgedmin> if you did a pip install --user -U pip, would it work? would it put a binary in ~/bin? ~/.local/bin?

[15:36:04] <cdunklau> and vendoring lets an upstream team deal with said incompatibilities their own way... but it makes it harder on downstream maintainers when upstream doesn't fix things in a timely fashion

[15:38:04] <cdunklau> mgedmin: needs a --force too

[15:38:09] <cdunklau> but it does appear to work

[15:39:02] <cdunklau> and then i need to do the same for virtualenv

[15:39:05] <cdunklau> aaaaaaah

[15:39:17] <cdunklau> screw it, i've spent too much time on this already

[15:39:55] <cdunklau> virtualenvs to the rescue. I only use user-site stuff for quick little one-off things anyway... virtualenvs for everything else

[15:40:10] <cdunklau> mgedmin: take it easy

Log file Viewer

Help | Karma | Search:

#pypa logs for Friday the 31st of October, 2014