pip install is downloading pre-release version without the --pre argument

• Pip version:10.0.1
• Python version:3.6.5
• Operating system:GNU/Linux (openSUSE Tumbleweed)

Dear all

I have created a new gnuhealth pre-release package using PEP440 versioning (3.3a1).

The problem is that if someone types "pip install --user gnuhealth" (without explicitly passing --pre as an argument) it will download the pre-release unstable version that is intended for developers and not for general users.

Any thoughts are most welcome.

Best
Luis

[benoit-pierre]

I think this is normal as it's the only version available on PyPi; see PEP 440.

Thanks !

I might be wrong, but IMHO, I don't think this should not be the behavior. A pre-release, regardless whether of the number of existing versions, should only be retrievable when using the --pre argument on pip. Otherwise, regular users will download it and get an unstable version.

Best

[benoit-pierre]

But that's not what PEP 440 says:

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.

(Emphasis mine).

hmm. I am not passing any version specifier as an argument to pip, but probably is not referring to this. In testpypi there are two pre-release versions and still behaves the same way.

[benoit-pierre]

I'm not seeing an issue when using test.pypi:

> pip download --index-url https://test.pypi.org/simple gnuhealth
Looking in indexes: https://test.pypi.org/simple
Collecting gnuhealth
  Downloading https://test-files.pythonhosted.org/packages/ae/aa/d04040b251f9edef6ee3b949ddf964a7568d17362738d6830515e5a43eac/gnuhealth-3.3.2.tar.gz (780kB)
    100% |████████████████████████████████| 788kB 10.5MB/s 
  Saved ./gnuhealth-3.3.2.tar.gz
Collecting pytz (from gnuhealth)
  Could not find a version that satisfies the requirement pytz (from gnuhealth) (from versions: )
No matching distribution found for pytz (from gnuhealth)

Thank you for the feedback !

Yes, you are right. I double checked on testpypi, and this is how it seems to work:

• If there is a non pre-release version of the package on pypi, then pip works as expected, ignoring the pre-releases.
• if the only versions on pypi are pre-releases, it will choose the latest pre-release, even if no "--pre" argument is provided.

We still have the problem. Regular users will download an unstable version of a package, which is not ideal. I don't get the PEP440 rationale on this.

Best,

[pfmoore]

I'd have thought the rationale is simple - if I ask for X, I should get X if at all possible. Ideally, a stable release, but a pre-release is better than nothing at all. If you don't want general users to install your pre-release package before you release your first stable version, you should probably simply not publish it on PyPI.

Hi there !
I don't agree.
IMHO, development / pre-releases are not necessarily better than nothing at all. They are made for developers, not end users. They are unstable and they might contain (more) security issues. They are not ready to be used.

Forcing the developer to explicitly ask for a pre-release, using the "--pre" argument in all scenarios should be the best and easiest approach. That's something that the developer knows, and the end user won't get the wrong package.

[pradyunsg]

I don't know if this is something that had been brought up when PEP 440 was being discussed. @meanmicio perhaps you can try to check if that's indeed the case (the discussions are archived on distutils-sig and you can see when the PEP was accepted on the PEP page).

Moreover, if pip's implementation has to be changed, we have to update PEP 440 before that. That's going to need to go through distutils-sig as that's where packaging related PEPs are discussed.

[pfmoore]

I agree with @pradyunsg - if you want this to change, you'll have to start by proposing a change to PEP 440 (which would be discussed on distutils-sig, not here). If (and only if) that change is accepted and implemented, then pip would change to follow the amended standard.

[techalchemy]

(Sorry for butting in) -- just to comment from our perspective (we had discussed how to handle implementation separately -- have not yet implemented it) - it makes sense that if a user requests to have something installed, and there only exists a prerelease version, you give them that. See the discussion here (which basically amounts to -- the PEP, pip, and warehouse all work this way, so should we): pypa/pipenv#2022 (comment)

WARNING! : Definitely logical and consistent content

I got bit by this bug on Win10 with tensorflow. Yay!

>pip install scipy
… installing (release/expected version) of scipy

>pip install tensorflow
… here, have a rc version. why this happened? See reason1.

Go to reason1 : - Link

This would have been better. For anyone who expects sane/intuitive defaults for mundane tasks; that need to be automated.

From pypa/pipenv#2022 (comment)

perhaps with a printed warning at install time about only pre-releases being available for that particular dependency.

always with a printed warning before downloading the file, about only ...