Log file Viewer

[02:25:55] <nedbat> i have a question about version specifiers in the latest pip: if I have a requirement "pkg <4.0", and pkg has a 4.0a1 release, and I install with --pre, will it install 4.0a1 ?

[02:36:28] <nedbat> with --pre, it installs 4.0a1, without --pre, it installs 3.7.1. Doesn't pep440 say it shouldn't install 4.0a1?

[02:37:27] <Alex_Gaynor> Ugh, I see the logic that led to 4.0a1 :-/

[02:37:33] <Alex_Gaynor> 4.0a1 < 4.0

[02:37:38] <Alex_Gaynor> which sort of makes sense

[02:37:55] <nedbat> Alex_Gaynor: sort of, but pep440 says, "The exclusive ordered comparison < V MUST NOT match a pre-release of the given version, even if acceptance of pre-releases is enabled as described in the section below."

[02:38:14] <Alex_Gaynor> sounds like a bug then, not sure if pip technically implements pep440 at all yet

[02:40:30] <nedbat> :(

[02:46:33] <Alex_Gaynor> nedbat: have you tried with pip from master?

[02:46:35] <nedbat> Alex_Gaynor: i'll write a bug, but i don't understand some of the existing ones: https://github.com/pypa/pip/issues/1505 is this what I'm talking about?

[02:46:40] <nedbat> Alex_Gaynor: no

[02:46:52] <Alex_Gaynor> nedbat: you might want to; I know dstufft has been working on PEP440 a bunch

[02:47:24] <dstufft> pip doesn't correctly follow PEP 440 right now

[02:47:27] <Alex_Gaynor> nedbat: that ticket is for something else I believe

[02:47:34] <dstufft> it half follows it

[02:47:43] <dstufft> because PEP 440 was approved only a few weeks ago

[02:47:59] <dstufft> right now version specifiers are still using setuptools style version specifiers

[02:48:40] <dstufft> in that the version specifiers themselves don't have any logic about pre-releases, so it sees 4.0a1 as less than 4.0

[02:48:53] <nedbat> dstufft: that's what I've been discovering, yes...

[02:49:39] <dstufft> you're correct in that PEP 440 stlye spcecifiers disinclude 4.0a1 if you do < 4.0

[02:49:55] <dstufft> setuptools just merged PEP 440 earlier today

[02:50:02] <dstufft> pip needs to merge that too

[02:50:07] <dstufft> and it'll be in the next release

[02:50:19] <nedbat> ok, cool. when will that be do you think?

[02:50:33] <nedbat> we fixed the problem with "coverage<3.999"

[02:50:41] <nedbat> but it'd be nice to say "<4.0"

[02:50:58] <dstufft> the "pre-release" stuff right now is essentially done as a distinct step currently, we get a list of versions from PyPI, we filter out things that don't match setuptools style specifiers, then we filter out things which are pre-releases (unless the pre-release flag is there)

[02:51:13] <dstufft> not sure an exact date, it should hopefully be soon, PEP 440 is the only big thing I was waiting on

[02:52:39] <nedbat> today has been a wild adventure of finding a number of infelicities while trying to release coverage 4.0a1

[02:53:29] <nedbat> who knew that tox specified --pre by default?

[02:53:45] <Alex_Gaynor> yeah, that seems wrong to me

[02:54:24] <nedbat> you and me both, brother!

[02:54:37] <dstufft> I think tox did that when we added --pre for some reason...

[02:54:39] <dstufft> I forget why

[02:54:51] <Alex_Gaynor> probably to preserve th eexising behavior?

[02:54:52] <nedbat> dstufft: because holger was used to getting prereleases

[02:54:54] <nedbat> right

[02:55:01] <Alex_Gaynor> yeah, what nedbat said

[02:56:18] <dstufft> yea quite possibly

[02:56:31] <dstufft> nedbat: sorryt his is all not so obvious :(

[02:56:41] <dstufft> the hidden thing on PyPI is terrible and it's gone

[02:57:20] <nedbat> dstufft: not sure what you're apologizing for, but no worries, i've just been stewing on this all day...

[02:57:26] <dstufft> it basically determines whether you get a page like this: https://pypi.python.org/pypi/Django or like https://pypi.python.org/pypi/Flask if you have multiple versions uploaded

[02:57:36] <dstufft> Warehouse changes that so it's always like the second one

[02:57:48] <dstufft> https://warehouse.python.org/project/Django/

[02:58:24] <dstufft> fwiw about pre-releases ->

[02:58:30] <dstufft> setuptools will still install them bydefault

[02:58:44] <dstufft> even with the PEP 440 branch, (it effectively hardcodes --pre to on right now)

[02:59:02] <dstufft> mostly because I got really mad trying to add --pre support to easy_install and got frustrated and gave up

[02:59:50] <dstufft> that really only affects people who a) use easy_install instead of pip b) do ``setup.py install`` on something that depends on coverage or c) have coverage inside of a setup_requires

[03:00:03] <dstufft> for c) pip will fix that sooner or later so it's only a or b

[03:00:22] <dstufft> but nothing pip can do about a and b, that requires actually digging into setuptools and getting --pre support

[03:00:46] <nedbat> dstufft: so Warehouse will only ever show the last release?

[03:01:37] <dstufft> nedbat: look at the right bar, right above the pictures

[03:02:05] <nedbat> oh, i see

[03:02:07] <dstufft> https://warehouse.python.org/project/Django/1.0.1/

[03:03:13] <dstufft> instead of having different behavior for the unversioned url based on if you have > 1 unhidden versions or not, the unversioned URL is just always the "latest" version (Although I need to adjust that stil so it's the latest non-prerelease, unless there are only pre-release available)

[03:05:24] <nedbat> right, cool.

[03:07:42] <nedbat> dstufft: thanks, you've set my mind at ease about the pre-release versions. The guy who pointed it out to me was trying to convince me that it was doing the right thing, because math. or something.

[03:31:04] <dstufft> nedbat: np!

[04:22:31] <isomorphismes> buck1: sorry I didn't watch irc for a few days. I'll paste the exact command and error

[04:23:18] <isomorphismes> https://dpaste.de/ZAir

[04:23:35] <isomorphismes> buck1: Let me know if you need me to re-copy what I said before.

[04:24:08] <isomorphismes> The exact command was $ gett filename

[04:24:38] <isomorphismes> I don't understand where I'm supposed to type import sys; print sys.path. Not in bash

[04:24:54] <isomorphismes> am I supposed to run iPython every time I want to run this command?

[04:25:19] <isomorphismes> or maybe edit some file in /usr/local/.../ ?

[16:09:09] <ionelmc> dstufft: shouldn't pypi be back now?

[16:10:35] <apollo13> ionelmc: status says 19utc iirc

[16:10:52] <apollo13> which is a few hours out

[16:10:56] <ionelmc> ah

[16:10:58] <ionelmc> oops

[16:11:05] <apollo13> timezones ;)

[16:11:13] <ionelmc> ... are hard xD

[16:13:53] <doismellburning> apollo13: <1

[17:29:37] <EWDurbin> ionelmc: pypi is back a little early :)

[17:29:40] <EWDurbin> enjoy

[17:29:50] <ionelmc> jihaaaaaaaa

[17:48:43] <[Tritium]> I am trying to set the `pip install --target ...` option from an environment variable, but it seams to be ignoreing $PIP_TARGET. I am using python 3.2, and calling pip as `pip3`. I am using pip 1.5.6. The problem it is encountering is that it is apparently still trying to install in a default location.

[17:50:00] <[Tritium]> https://gist.github.com/tritium21/ffcdc80ad4f1d44c3caa