0

Is there a way to tell the package manager pip to never replace newer by older versions when installing packages from a requirements.txt?

Example: I have Robot Framework 3.2.2 and Waitress 1.4.3 installed and my requirements.txt looks like this:

...
robotframework==3.0.2
waitress==1.4.4
...

Hence, I would only want the waitress requirement to be refreshed. The reason is that I need to automate the installation of dependencies via requirement files and can't just change their content.

Bryan Oakley
  • 370,779
  • 53
  • 539
  • 685
elsamuray7
  • 79
  • 1
  • 10
  • 1
    "I can't just change their content" doesn't make much sense, i.e. in the situation described `requirements.txt` is outdated. What if there are new or depreciated functionality between installed version and listed in `requirements.txt`. – buran Feb 22 '21 at 11:33
  • 1
    Why do you have newer versions installed in your environment when `requirements.txt` states the older ones? This might lead to incompatibility issues. The `requirements.txt` file is here to specify the exact (or range of) versions that should be used. – Yevhen Kuzmovych Feb 22 '21 at 11:35
  • @YevhenKuzmovych It is a tool with which I can remote-execute python software. I can't give an explaination of the exact use case. On upload it scans the uploaded software (which most likely is a zip file that contains a project folder) for a `requirements.txt`. If it finds one then it installs the dependencies. I don't want the requirements file to uninstall dependencies that are required by my tool at the first place. Probably I would need to scan the requirements file and evaluate all the dependencies manually before installing them. – elsamuray7 Feb 22 '21 at 12:25
  • @buran Its still a bad behavior to silently downrade packages when having an outdated requirements file isn't it? The correct behaviour would be to ask the user: `WARNING: You have already a newer version of module xyz installed. Would you like to continue? This may break your python environment! (y|n)` and on top of that a user should be able to set the default behavior to *failure* when a requirements file contains older versions. – elsamuray7 Feb 22 '21 at 14:52
  • The idea of `requirements.txt` is to repeatedly recreate a complete specific environment, e.g. for development, when multiple contributors, etc.. If your requirements.txt does not reflect your actual environment, it defy it purpose. I suggest you read https://stackoverflow.com/questions/43658870/requirements-txt-vs-setup-py and https://packaging.python.org/discussions/install-requires-vs-requirements/ – buran Feb 22 '21 at 15:30
  • @buran I know the purpose of that file. That still doesn't mean that you want to permit `pip` to possibly break your python environment when you download a project that contains a `requirements.txt` and you run it. I spent the last hours to find a solution and saw a lot of related issues and discussions in the `pip` repository. Seems like even some of the contributors share my opinion - but also means that currently there is no simple solution for the problem. – elsamuray7 Feb 22 '21 at 16:30
  • @buran Also just to make things clear. The `pip` documentation explicitly states that one may run `pip` from within a `subprocess`, so the automation of dependency installation with a requirements file is nothing that is not recommended by the authors. – elsamuray7 Feb 22 '21 at 16:34

1 Answers1

0

You could use >= to tell pip to install newer versions, or that version.

For example:

robotframework>=3.0.2
waitress>=1.4.4

Would tell pip to install any version that is at least 3.0.2 for robotframework, and at least 1.4.4 for waitress.

PotentialStyx
  • 424
  • 4
  • 11