Skip to content
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

[BUG] Installations like >=2.0.0 dont update the existing older version 1.0.0 of any package #12396

Closed
1 task done
aiwalter opened this issue Nov 9, 2023 · 4 comments
Closed
1 task done
Labels
type: support User Support

Comments

@aiwalter
Copy link

aiwalter commented Nov 9, 2023

Description

When I do an installation sequence of e.g following where pydantic is just an exmaple, I got same issue with other packages like langchain, see langchain-ai/langchain#13069

pip install pydantic==2.0.0
pip install pydantic>=2.4.2
pip show pydantic

This returns:

Name: pydantic
Version: 2.0
.
.
.

It is keeping 2.0.0 for some reason, is this intended?

Expected behavior

I would expect that the pydantic==2.0.0 will be uninstalled and replaced with a more recent version.

pip version

23.3.1

Python version

3.11.5 and 3.8.0

OS

Windows and Unix

How to Reproduce

pip install --upgrade pip
pip install pydantic==2.0.0
pip install pydantic>=2.4.2
pip show pydantic

Output

Name: pydantic
Version: 2.0
Summary: Data validation using Python type hints
Home-page: 
Author: 
Author-email: Samuel Colvin <s@muelcolvin.com>, Eric Jolibois <em.jolibois@gmail.com>, Hasan Ramezani <hasan.r67@gmail.com>, Adrian Garcia Badaracco <1755071+adriangb@users.noreply.github.com>, Terrence Dorsey <terry@pydantic.dev>, David Montague <david@pydantic.dev>
License: 
.
.
.

Code of Conduct

@aiwalter aiwalter added S: needs triage Issues/PRs that need to be triaged type: bug A confirmed bug or unintended behavior labels Nov 9, 2023
@edmorley
Copy link
Contributor

edmorley commented Nov 9, 2023

The reason is that the shell is seeing the unquoted > character and is redirecting stdout to a file named =2.4.2.

This is why the output from the pip install pydantic>=2.4.2 step (which was omitted from the filed issue), only contains the contents of stderr. Inspecting the =2.4.2 file, pip's stdout can be seen:

$ docker run --rm -it python:3.11.5-slim bash
root@27c8adaab242:/# pip install --upgrade pip
...
root@27c8adaab242:/# pip install pydantic==2.0.0
...
root@27c8adaab242:/# pip install pydantic>=2.4.2
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
root@27c8adaab242:/# cat =2.4.2
Requirement already satisfied: pydantic in /usr/local/lib/python3.11/site-packages (2.0)
Requirement already satisfied: annotated-types>=0.4.0 in /usr/local/lib/python3.11/site-packages (from pydantic) (0.6.0)
Requirement already satisfied: pydantic-core==2.0.1 in /usr/local/lib/python3.11/site-packages (from pydantic) (2.0.1)
Requirement already satisfied: typing-extensions>=4.6.1 in /usr/local/lib/python3.11/site-packages (from pydantic) (4.8.0)

If you add quotes around the dependency specifier, the newer version is installed as expected:

root@27c8adaab242:/# pip install 'pydantic>=2.4.2'
Collecting pydantic>=2.4.2
  Downloading pydantic-2.4.2-py3-none-any.whl.metadata (158 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 158.6/158.6 kB 7.5 MB/s eta 0:00:00
Requirement already satisfied: annotated-types>=0.4.0 in /usr/local/lib/python3.11/site-packages (from pydantic>=2.4.2) (0.6.0)
Collecting pydantic-core==2.10.1 (from pydantic>=2.4.2)
  Downloading pydantic_core-2.10.1-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl.metadata (6.5 kB)
Requirement already satisfied: typing-extensions>=4.6.1 in /usr/local/lib/python3.11/site-packages (from pydantic>=2.4.2) (4.8.0)
Downloading pydantic-2.4.2-py3-none-any.whl (395 kB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 395.8/395.8 kB 14.6 MB/s eta 0:00:00
Downloading pydantic_core-2.10.1-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (1.8 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.8/1.8 MB 19.9 MB/s eta 0:00:00
Installing collected packages: pydantic-core, pydantic
  Attempting uninstall: pydantic-core
    Found existing installation: pydantic_core 2.0.1
    Uninstalling pydantic_core-2.0.1:
      Successfully uninstalled pydantic_core-2.0.1
  Attempting uninstall: pydantic
    Found existing installation: pydantic 2.0
    Uninstalling pydantic-2.0:
      Successfully uninstalled pydantic-2.0
Successfully installed pydantic-2.4.2 pydantic-core-2.10.1
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv

This is why there are quotes around the examples in the pip install docs:
https://pip.pypa.io/en/stable/cli/pip_install/#examples

Those docs also link to this more general "requirements specifiers" page:
https://pip.pypa.io/en/stable/reference/requirement-specifiers/#requirement-specifiers

...which says:

Note

Use quotes around specifiers in the shell when using >, <, or when using environment markers.

That said, it's a totally understandable mistake to make - I just don't think there's any way from pip's side to try and make this easier to debug in the moment - since pip is already outputting the right thing to stdout (which would explain the issue), but the user just can't see it because the shell has redirected it to a file.

The only real long term solution would be for shells to warn on redirect characters being used without whitespace either side of them perhaps - but that's unlikely to be something that is every viable for them to do given likely thousands of valid scripts in the wild that have omitted the whitespace. Or perhaps a shellcheck lint could be created to warn about potentially unintended redirects?

See also #12116, #11376, #7505, #938.

@aiwalter
Copy link
Author

aiwalter commented Nov 9, 2023

Hi @edmorley , thx for quick response! How would that work in a requirements.txt file with the quotes? I have never seen that in a requirements.txt file? I think user expectation is that my above example would update existing installation? For me it still feels like its a bug, but possibly too big to fix it since it would possibly affect a lot of production code?

@edmorley
Copy link
Contributor

edmorley commented Nov 9, 2023

Quotes must not be used in requirements files (and are not needed). From the docs I linked above:

Do not use quotes in requirement files. There is only one exception: pip v7.0 and v7.0.1 (from May 2015) required quotes around specifiers containing environment markers in requirement files.

This issue is specifically about how a shell works. When you list a dependency in a pip install command typed in a shell (or in a shell script), it's not the same as copying that command 1:1 into a requirements file.

For me it still feels like its a bug, but possibly too big to fix it since it would possibly affect a lot of production code?

This is not a pip issue. You're using characters that the shell treats as having special meaning. So you need to add quotes to tell the shell to ignore those characters and pass them verbatim to pip. Otherwise pip never gets the full command you typed.

It might help for you to read:
https://www.gnu.org/software/bash/manual/html_node/Quoting.html
https://www.gnu.org/software/bash/manual/html_node/Redirections.html

@pradyunsg pradyunsg added type: support User Support and removed type: bug A confirmed bug or unintended behavior S: needs triage Issues/PRs that need to be triaged labels Nov 10, 2023
@pradyunsg
Copy link
Member

Thanks @edmorley for assisting here! ❤️

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 11, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type: support User Support
Projects
None yet
Development

No branches or pull requests

3 participants