Implicit prerelease detection logic makes versions like 1206 unable to install #1555

Closed
techtonik opened this Issue Feb 11, 2014 · 17 comments

Projects

None yet

6 participants

@techtonik
Contributor

The prerelease intelligence is really getting in the way. I can't upgrade my code review update tool, because pip threats version numbers like 1206 as prereleases.

https://pypi.python.org/pypi/review

@techtonik
Contributor

pip 1.5.2

Ignoring link https://pypi.python.org/packages/source/r/review/review-1206.zip#md5=9734eaf5f5a2567efce387e744a6de14 (from https://pypi.python.org/simple/review/), version 1206 is a pre-release (use --pre to allow).
Ignoring link https://pypi.python.org/packages/source/r/review/review-695.tar.gz#md5=3938d42eae9261bb0c5fe68c6311e3b3 (from https://pypi.python.org/simple/review/), version 695 is a pre-release (use --pre to allow).
Ignoring link https://pypi.python.org/packages/source/r/review/review-709.tar.gz#md5=ce39d74d86b208ca9de888296403df15 (from https://pypi.python.org/simple/review/), version 709 is a pre-release (use --pre to allow).
@qwcode
Contributor
qwcode commented Feb 11, 2014

2 things here:

  1. pip is using distlib under the covers, and distlib seems wrong to think something like '695' is not PEP440-compliant (which right now, categorizes it as a pre-release). It only works if you use '695.0' @vsajip ?
  2. see #1505, we plan on logically separating the PEP440 filter from the pre-release filter. This should make it clearer, and give users more power to control which versions get found.
@techtonik
Contributor

For 2. I'd actually prefer to have #1557 because it is not the first time I am wasting too much time, because pip (again) magically didn't update to the latest version. It says ok and you didn't expect that something could go wrong expecting that your soft is updated.

@vsajip
Contributor
vsajip commented Feb 11, 2014

Soon after PEP 440 was updated to allow single-number versions, the distlib implementation has allowed that:

>>> from distlib.version import NormalizedVersion as V
>>> V('695')
NormalizedVersion('695')
>>> V('695').is_prerelease
False

However, pip's vendoring of distlib pre-dates that change in distlib.

@techtonik
Contributor

So how to link that to the event when distlib sees a new release?

@dstufft
Member
dstufft commented Feb 20, 2014

pip uses the latest version of distlib on PyPI already.

@techtonik
Contributor

Does this latest released version fix the bug?

@vsajip
Contributor
vsajip commented Feb 21, 2014

Does this latest released version fix the bug?

No - and this was not a distlib bug - it was a change made to track changes in PEP 440 (which previously did not allow single-number versions) . The change is available in the distlib repository but has not yet been released. Even if it were released, that doesn't mean it would immediately be incorporated into pip. Since Python 3.4 is now in release-candidate mode (critical fixes only), I'm not sure how that plays into any updated releases of pip.

@Ivoz
Member
Ivoz commented Feb 21, 2014

ensurepip is a new module, so its not in critical fixes mode, the same as asyncio.

If distlib was currently in a stable state, and made a new release, @dstufft could consider pulling it in with 1.5.4. That's not with any certainty, though.

@techtonik
Contributor

I'd say that this bug is critical, because it is a regression. I am not 100% sure, because it may be that previously the way to install my packages with not through pip, but through easy_install, but the fact is - current user instruction doesn't work.

@dstufft
Member
dstufft commented Feb 24, 2014

This missed the cut off for CPython 3.4. Pip will update itself once distlib releases a new version and it'll be rolled into 1.6. Anyone who needs this after that can upgrade their pip.

@dstufft
Member
dstufft commented Feb 24, 2014

@mgedmin reported in #1549 that this was causing pdfminer to require the --pre flag to install as well.

@mgedmin
mgedmin commented Feb 24, 2014

FWIW PEP 440 always allowed single-value version numbers, according to the author of PEP 440. The recent change was merely a clarification, because people misinterpeted the original pseudo-syntax.

@Ivoz
Member
Ivoz commented Feb 24, 2014

Damn right they misinterpreted that, every regular language under the sun uses + as 1 or more and * as 0 or more.

@vsajip
Contributor
vsajip commented Feb 24, 2014

FWIW PEP 440 always allowed single-value version numbers, according to the author of PEP 440

Well, PEP 440 was extracted from PEP 426, and that was based on the proposals in PEP 386 - which don't support single number versions. distlib started with the PEP 386 implementation (which didn't support single-number versions), and added a LegacyVersion class which is just as permissive as setuptools. The NormalizedVersion class, which aims to follow PEP rules, was originally PEP 386 compliant (as that was the only relevant PEP), then adopted PEP 426 (which didn't drop the single-number proscription, but added useful functionality relating to .dev / .post ordering), and now aims to follow PEP 440 (possibly single-number was allowed in the earliest version of PEP 440 - but I'm not sure, and anyway it doesn't matter - the earlier PEPs which the distlib implementation tracked didn't allow them).

@techtonik
Contributor

This excuses look to me as legalese from which I'd like to opt-out. Too bad people don't get the concept of UX and user stories right. =/

@Ivoz
Member
Ivoz commented Feb 26, 2014

It's not an excuse in any way, shape or form. It's an explanation of history for those interested.

Too bad people don't get the concept of UX and user stories right. =/

Making passive aggressive statements doesn't help anyone further their case.

@dstufft dstufft closed this in #1750 Apr 24, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment