-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pip install is downloading pre-release version without the --pre argument #5503
Comments
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 |
But that's not what PEP 440 says:
(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. |
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:
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, |
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 ! 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. |
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. |
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. |
(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 contentI 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)
always with a printed warning before downloading the file, about only ... |
If you totally agree with issue #5503 (comment) ; I have a new project that you'll like. Just 😕 & 🚀 this post if you want a link. I'll put it afterwards in the 'Project Link' (expandable). Project LinkTo be edited |
https://www.python.org/dev/peps/pep-0440/#handling-of-pre-releases may not be wrong. |
|
|
click to expand
I guess this hinges on PEP508 agrees with me & the users on what https://www.python.org/dev/peps/pep-0508/#names
https://www.python.org/dev/peps/pep-0345/#version leads to PEP440. https://www.python.org/dev/peps/pep-0345/#name
For example it would be I guess it's PEP 508+345+440+
I know that pressure builds on developers. Some people may want the convenience, but does it fall into the general expectations? For eg, if you tried:-
release-candidate/beta/alpha/dev or latest-version. I expect latest-version. No pre-release version. I'll try to see if pipenv protects an environment from |
Tensorflow is safe to use since stable release v1.13 . But the issue still remains unresolved. |
Let's consider we have a package with the following versions (all are pre-releases):
And if I run But if I run I see a controversy here. |
I'm running into this as well. IMO, it would be better to error out than to install pre-release software by default. I'd like to install the latest normal release, binary only, without needing to specify a version. Here's a quick rundown of what I see in a venv: $ pip --version
pip 23.0.1 from /tmp/pip-5503/lib64/python3.11/site-packages/pip (python 3.11)
$ python --version
Python 3.11.2
$ pip install --only-binary=:all: connectorx
Collecting connectorx
Using cached connectorx-0.3.2_alpha.2-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (47.1 MB)
Installing collected packages: connectorx
Successfully installed connectorx-0.3.2a2 In this specific case, it looks like since I'm on Python 3.11, and the latest normal release for connectorx (3.1) does not contain binary wheels for python 3.11, it decides to install the pre-release version which does contain Python 3.11 binary wheels. Ideally, this command would error out by default. Since that's not the case today, is there a flag I can specify to explicitly turn off all form of pre-release wheels? Note: on Python 3.10, connectorx 3.1 is correctly installed. |
It looks like PEP440 says tools SHOULD allow this alternative behavior:
IMO, this could be satisfied by a |
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
The text was updated successfully, but these errors were encountered: