relaxing version pinning in requirements.txt?

[ickc]

Would you consider relaxing the version pinning in this file:

https://github.com/rhayes777/PyAutoFit/blob/66c7fd2962dc11ce513f652fe9df82eece960ac3/requirements.txt

If pinning is really needed for reproducibility, may be it can be moved to a separate lock file?

Pinning like this can causes issues when solving for an environment with other dependencies resulting in no solution.

[Jammy2211]

In the past, we did not use pinning, but found it created a different problem which was a new version of Numpy, Scipy, or some other library would be released and via some form of incompatibility mean installation did not work for users.

Pinning was chosen to ensure that a user's pip install is always reliable.

Note that we have a build server which currently runs manually, but the intention is to automatically run. Nevertheless, when it does run, it verifies against all Python versions that the pinning ensures a clean install for a fresh virtual enviroment:

https://github.com/Jammy2211/PyAutoBuild/actions

Pinning like this can causes issues when solving for an environment with other dependencies resulting in no solution.

We are working under the assumption that installation is using a fresh conda of Python virtualenv, I think installing into any enviroment with existing dependencies is going to cause issues irrespective of how requirements.txt is setup.

[ickc]

Right. But version pinning is more about reproducing an environment that is known to work correctly. So the problem is that end users shouldn't be relying on pip install $PACKAGE to get a reproducible environment.

Version constraining if setup properly per dependencies should work, and if it doesn't, then it is a problem of some of the downstream dependencies that doesn't set it up properly. In that case, ideally, it can be fixed downstream and also have the problematic version(s) excluded.

Version pinning, which can be used to reproduce a known working environment, can be put in a lock file. Other tools has functionality doing this, but a requirements_pinned.txt could do the job, where end users can be directed to use that instead in the doc. Or perhaps we can put the pinning as a feature and do something like pip install autolens[pinned].

The problem of having version pinning directly in requirements.txt where setup.py read and set as requirement, is that it becomes hardcoded and impossible to override, except may be with --no-deps or manually changing that file.