pmxbot IRC Log Viewer

[16:44:25] <msabramo> looks like pip 6 is becoming a thing

[16:44:49] <sigmavirus24> msabramo: give it another 6 months =P

[16:44:58] <sigmavirus24> in all seriousness, I'm excited for pip6

[16:45:03] <msabramo> me too

[16:45:12] <sigmavirus24> I hear it will be forward compatible with python 6000

[16:45:41] <msabramo> cool, I'm sure our ancestry will appreciate that

[17:02:00] <vgnbkr> Hi all. Don't know if this is the correct forum for this, but I just (inadvertently) got today's update to pip and there seems to be a problem. "pip install 'prettytable>0.7'" fails, even though the current version seems to be 0.7.2. How do I tell what version it thinks it is?

[17:06:16] <dstufft> vgnbkr: moment

[17:11:44] <msabramo> vgnbkr: Same here

[17:11:46] <msabramo> [marca@marca-mac2 ~]$ pip install 'prettytable>0.7'

[17:11:46] <msabramo> Collecting prettytable>0.7

[17:11:46] <msabramo> Could not find a version that satisfies the requirement prettytable>0.7 (from versions: )

[17:11:46] <msabramo> No distributions matching the version for prettytable>0.7

[17:11:49] <msabramo> let's see

[17:12:10] <msabramo> pip install -v is typically useful for things like this

[17:14:05] <msabramo> hmm there is no message about why it didn't use 0.7.2 that I can see

[17:14:27] <msabramo> Found link https://pypi.python.org/packages/source/P/PrettyTable/prettytable-0.7.2.tar.gz#md5=a6b80afeef286ce66733d54a0296b13b (from https://pypi.python.org/simple/prettytable/), version: 0.7.2

[17:14:27] <msabramo> Found link https://pypi.python.org/packages/source/P/PrettyTable/prettytable-0.7.2.zip#md5=0c1361104caff8b09f220748f9d69899 (from https://pypi.python.org/simple/prettytable/), version: 0.7.2

[17:15:18] <msabramo> workaround: `pip install 'prettytable>0.7.0'`

[17:16:16] <msabramo> me thinks the new versioning stuff broke the comparison of versions, specifically when you require '>a.b' and the newer package is 'a.b.c'

[17:16:34] <dstufft> Alright sorry

[17:16:37] <dstufft> vgnbkr: https://bitbucket.org/pypa/setuptools/issue/301/101-in-requirementparse-foo-10-results

[17:16:45] <dstufft> more or less >V implies !=V.*

[17:16:54] <dstufft> so >0.7 implies !=0.7.*

[17:20:57] <msabramo> dstufft: I think I get the reasoning; I wonder if this will create a lot of confusion though

[17:21:25] <msabramo> I guess usually people would put >= instead of > though

[17:21:52] <sigmavirus24> msabramo: in fairness, the existing behaviour always confused me. I think the new behaviour is a lot more explicit personally

[17:22:13] <sigmavirus24> (probably just me though)

[17:22:23] <msabramo> sigmavirus24: the confusing part of the old behavior for me was that if you said '<1.0', you still got '1.0a1'

[17:22:49] <msabramo> though I don't run into those pre-release versions very often

[17:23:00] <sigmavirus24> msabramo: Yep

[17:23:24] <msabramo> I'm not a huge fan of pre-releases because they create this weird exception

[17:24:02] <msabramo> 1.0 < 1.0.x unless x is "a*" or "dev*" or whatever

[17:24:03] <msabramo> bah

[17:24:04] <vgnbkr> But if you say >1.0, you do want 1.0a1.

[17:24:54] <msabramo> vgnbrk: yeah, I think I'd agree with that

[17:25:03] <msabramo> oops, vgnbkr

[17:25:29] <vgnbkr> A "depricated in next release" would have been nice on something like this that has the potential to break a lot of stuff.

[17:25:42] <msabramo> I am a little worried that I am going to be fielding a lot of questions about this

[17:26:06] <dstufft> you don't find a lot of pre-releases in the wild because the old behavior made it very painful to deal with them

[17:26:31] <msabramo> yeah

[17:26:32] <sigmavirus24> vgnbkr: it's not exactly deprecated so much as fixed

[17:26:50] <msabramo> when I do have pre-release stuff, I tend to just pull it from a VCS

[17:26:53] <sigmavirus24> vgnbkr: also going from 1.5.6 -> 6.0.0 should be a hint there are some impactful changes

[17:27:16] <msabramo> 1.5.6 -> 6.0.0 I would expect crazy changes

[17:27:21] <sigmavirus24> I did my first alpha release with 1.0.0a1 of github3.py to have something people could use

[17:27:43] <sigmavirus24> msabramo: I am expecting pip to now use NPM too as an alternative index and install JS packages =P

[17:27:46] <msabramo> sigmavirus24: I love github3.py by the way

[17:27:54] <sigmavirus24> msabramo: I'm glad to hear that

[17:27:59] <vgnbkr> sigmavirus24, This was automatically upgraded on me - I had no say.

[17:28:15] <msabramo> sigmavirus24: ha ha, I was going to say something very similar about pip installing packages from another language

[17:28:16] <sigmavirus24> vgnbkr: who or what upgraded pip for you automatically?

[17:28:27] <sigmavirus24> msabramo: get out of my head

[17:28:32] <msabramo> :)

[17:28:45] <msabramo> maybe vgnbkr did pip install —upgrade something?

[17:28:56] <msabramo> I guess I should test whether that would do it

[17:29:26] <vgnbkr> I was running Trove's redstack script, but I think it might be the Openstack devstack script that actually did it. I'm surprised there aren't thousands screaming.

[17:29:35] <sigmavirus24> oh wait. 6.0 is officially out? I totally missed that

[17:29:51] <msabramo> bummed that my green PR didn't make it in for Christmas :)

[17:29:56] <sigmavirus24> vgnbkr: thousands screaming out in silence at the horror that is better versioning

[17:30:02] <msabramo> sigmavirus24: yep, it's out

[17:30:08] <sigmavirus24> msabramo: I missed that totally

[17:30:16] <sigmavirus24> Is virtualenv out too?

[17:30:23] <msabramo> well I didn't notice it until vgnbkr posted about it

[17:30:28] <msabramo> then I went to repro his prob

[17:31:35] <msabramo> well I think there are things better about this change, but it also has an aspect that is confusing for some

[17:31:48] <sigmavirus24> agreed

[17:32:05] <msabramo> but I do wonder if you really need PrettyTable>0.7 instead of PrettyTable>=0.7

[17:32:50] <msabramo> is there something wrong with PrettyTable==0.7?

[17:33:13] <sigmavirus24> msabramo: sorry?

[17:33:26] <vgnbkr> Unfortunately, I can't find a reference to prettytable, so it must be in a dependency.

[17:35:00] <msabramo> I'm a little worried that folks may come to me asking why they can't install stuff because of this; but OTOH my hope is that they are using '>=' not '>', so maybe it won't be much of an issue

[17:35:29] <msabramo> vgnbkr: ah, this is where pipdeptree would be useful

[17:35:50] <msabramo> that will help you find out who is requiring it

[17:39:21] <vgnbkr> msabramo, thanks, will check it out

[17:39:45] <sigmavirus24> msabramo: question: Were you able to reproduce vgnbkr's problems with the version number because in a tmp venv with setuptools 8.2.1 and pip 6.0.0 I can't

[17:39:59] <sigmavirus24> pip install 'prettytable>=0.7' installs 0.7.2 for me

[17:40:45] <msabramo> sigmavirus24: I was

[17:40:54] <msabramo> oh maybe I didn't have the latest setuptools

[17:40:56] <msabramo> let's see

[17:41:33] <qwcode> this != V.* deal is so odd... trying to come to terms with it

[17:42:28] <msabramo> [marca@marca-mac2 ~]$ pip list | egrep 'pip|setuptools'

[17:42:28] <msabramo> pip (6.0)

[17:42:28] <msabramo> setuptools (8.2.1)

[17:42:57] <vgnbkr> prettytable>=0.7 will work, it's prettytable>0.7 that fails

[17:42:59] <msabramo> sigmavirus24: Are you sure your shell is invoking the right pip? `hash -r` perhaps

[17:43:08] <msabramo> oh right

[17:43:11] <msabramo> > instead of >=

[17:43:15] <sigmavirus24> vgnbkr: ah, misunderstood taht

[17:43:33] <msabramo> yeah it's subtle

[17:45:26] <qwcode> dstufft, how much was !=V.* argued on distutils? looking for where this came up?

[17:46:47] <dstufft> sigmavirus24: it's pip install >0.7

[17:46:49] <dstufft> not >=0.7

[17:47:08] <dstufft> qwcode: um, I don't think anyone argued about it

[17:47:21] <dstufft> it's been in the PEP for a long time, don't think anyone said anything about it

[17:47:40] <dstufft> the situation is that we wanted <8 to *not* match <8.dev0

[17:47:43] <sigmavirus24> The pep was discussed a whole bunch

[17:47:46] <dstufft> that's what people generally expect

[17:47:52] <dstufft> the PEP itself was yes

[17:47:56] <dstufft> that specific rule ID on't think was

[17:48:05] <qwcode> dstufft, that bit was too hard for anyone to follow on a casual read. I see the argument about pre-releases, but still pondering this.

[17:50:27] <dstufft> qwcode: was it really hard to understand that bit? it's like 3 paragraphs and it seems to pretty clearly state that it won't match

[17:50:48] <qwcode> dstufft, hard to swallow that 0.7.2 is not > 0.7

[17:51:51] <sigmavirus24> qwcode: we agree that 0.7.2 > 0.7.0, right?

[17:52:01] <sigmavirus24> is 0.7.0 > 0.7?

[17:52:07] <sigmavirus24> if we're doing a string match, yes

[17:52:26] <sigmavirus24> versions aren't just strings though

[17:52:43] <qwcode> dstufft, gotta run. will try to not to overract, and think it thru before saying anything more : )

[17:54:02] <dstufft> I don't think it's entirely intuitive for 0.7.1 > 0.7 to be false, but when I looked, almost nobody used > (they almost always used >=) so we chose this behavior for consistency with <

[17:54:12] <vgnbkr> sigmavirus24, re 0.7.0 - interesting point, but is 0.7 < 0.7.0?

[17:54:48] <sigmavirus24> vgnbkr: better question, is 0.7 == 0.7.0?

[17:55:07] <dstufft> 0.7 is == 0.7

[17:55:08] <dstufft> er

[17:55:09] <dstufft> 0.7.0

[17:55:11] <dstufft> whatever

[17:55:16] <vgnbkr> sigmavirus24, right - basically, there probably isn't a correct answer

[17:55:17] <dstufft> we pad zeros as needed

[17:55:35] <dstufft> we tried to do what people expected, and what was consistent

[17:55:58] <dstufft> that's why you see <8 not matching 8.dev0 even though 8.dev0 is less than 8

[17:56:06] <dstufft> (that's the do what people expect)

[17:56:11] <sigmavirus24> right

[17:56:16] <dstufft> and >0.7 not match 0.7.1 (that's the be consistent)

[17:56:23] <vgnbkr> As implemented in 6.0, it's probably more correct than before, just different enough that a warning would have been nice.

[17:56:39] <sigmavirus24> vgnbkr: a "Did you mean >0.7.0" kind of warning?

[17:57:49] <vgnbkr> More of a "WARNING: >7.0 behaviour will change in 6.1" type of thing.

[17:58:44] <vgnbkr> But, I realize that this is probably an unexpected consequence.

[18:03:43] <msabramo> perhaps a warning should be added for this case to pip 6.0.1?

[18:04:31] <msabramo> Warning: Found prettytable==0.7.2 but you specified prettytable>0.7 and the meaning of > has changed to that this doesn't include 0.7.X because of ...

[18:05:15] <msabramo> right now, I didn't even see anything in the output of `pip install -v`, which means it's really hard to figure out what's going on if you don't know the rules changed

[18:06:06] <msabramo> and I think a lot of people don't read the PEPs so they wouldn't know this was coming

[18:06:50] <msabramo> "Warning: Found prettytable==0.7.2 but you specified prettytable>0.7 and the meaning of > has changed to that this doesn't include 0.7.X because of … Maybe you meant to say prettytable>=0.7.2 (note the equals sign)"

[18:11:22] <vgnbkr> That would certainly have helped.

[18:12:21] <vgnbkr> Funny part is I found the offending script - it's trying to fix a pip 1.3 permissions bug and has a comment that says "remove when pip 1.4 is available everywhere" :-)

[19:26:56] <msabramo> vgnbkr: Do you think that this would've helped? https://github.com/pypa/pip/pull/2253

[19:52:05] <msabramo> awesome. py32 is the *first* build to succeed now

[19:52:13] <sigmavirus24> msabramo: just your luck ;)

[19:53:01] <msabramo> we should all use py32. new enough that you might use something that doesn't support it; but not *too* new in case you don't like the bleeding edge

[20:00:39] <vgnbkr> msabramo, Yes, that would have saved a bit of time and searching.

[20:01:25] <vgnbkr> To follow up, I see that the Openstack devstack team has a patch in flight to change ">" to ">=", so once that merges we'll be back on track.

[20:01:31] <vgnbkr> Thanks for the fast help, guys.

[20:08:22] <sigmavirus24> msabramo: no

[20:08:30] <sigmavirus24> py33 is new enough but not too antiquated

[20:08:37] <sigmavirus24> py34 is still the best py3x so far

[20:08:56] <sigmavirus24> 33 means more code that runs on 27 will run on 33 with fewer changes

[20:09:05] <sigmavirus24> (see adding u"" back in py33)

[21:06:35] <AlexMeng> why did pip go from version 1.5 to 6.0? was that intentional?

[21:14:35] <tomprince> AlexMeng: Dropped the leading 1.

[21:18:43] <sigmavirus24> tomprince: did it go missing? why wasn't there a reward put out to find it and return it back to its rightful place?

[21:26:21] <tomprince> sigmavirus24: Removing it removes the tempation to make big changes in 2.0.

[21:27:23] <sigmavirus24> sounds like it wasn't a very functional change (it had side effects) =P

[21:43:16] <msabramo> sigmavirus24: my py32 comment wasn't serious

[21:43:25] <sigmavirus24> msabramo: *whew*

[21:43:33] <sigmavirus24> I was worried about you for a second there =P

[21:43:46] <msabramo> I was the one who wanted to remove it before we realized PyPy3 uses it

[21:44:36] <msabramo> my work is all 2.7; if I convinced them do to do py3, it would be 3.5

[21:49:19] <sigmavirus24> 3.5 is shaping up to be excellent

Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Monday the 22nd of December, 2014