Hi, I recently filed pip issue #7579, because pip surprised an user by installing a prerelease while there was a stable release satisfying the version specifier. Specifically, the dependency specifier was
>=0.6.22rc1, and despite
--pre not being passed and
0.6.22 being available,
0.7rc2 was installed.
The wording in PEP 440 here is not clear, but I still think it’s unambiguous:
Pre-releases of any kind, including developmental releases, are implicitly excluded from all version specifiers, unless they are already present on the system, explicitly requested by the user, or if the only available version that satisfies the version specifier is a pre-release.
Note the “all”: All version specifiers (including the ones containing
X.YrcZ) have rcs excluded unless the user explicitly requested them being enabled (using a global statement of intent like
--pre). I think the behavior exhibited by pip is only technically correct (because the PEP says “should” and not “must”), but not what an user would expect. I’d expect pip to behave like this when
>=0.6.22rc1 is requested:
--preis given, the newest available version is installed, no matter if prerelease or not.
--preis not given, and a stable version satisfying the specifier is available, it is installed.
--preis not given, and no stable version satisfying the specifier is available, the highest available
0.6.22prerelease is installed.
This has implications for the PEP (which I think should be modified to be more clear for this case) and for the documentation/semantics of
packaging.specifiers.SpecifierSet (I would link it but for some reason I can’t put 3 links), which doesn’t distinguish between a global preference like
--pre and what’s encoded in the specification string. I think it makes no sense to derive this global preference from a specifier string, so the default should be
SpecifierSet(specifiers, prereleases=False), and
SpecifierSet('>=0.6.22rc1') should therefore mean one of the “
--pre is not given” cases above.
/edit: Also this is thread 3000, which clearly means that it’s the future of Python