We maintain minimum constraints files in our projects that define the minimum versions with == and are used with the -c option of pip. That allows setting up a virtual Python env with exactly the minimum versions of the dependent packages in order to test against that minimum set of versions.
Recently we started dividing the minimum-constraints files up into one with just the direct and indirect dependencies for installing our package, and one for everything, i.e. what is needed for development of the package and what is needed for installation.
In order to avoid duplicate maintenance of the dependencies for installation, we ended up with two minimum constraint files:
minimum-constraints-install.txt with just the direct and indirect dependencies for installation
minimum-constraints.txt that includes minimum-constraints-install.txt with -c and then defines just direct and indirect dependencies for development.
Pip understands this perfectly, but we must use -c minimum-constraints-install.txt to include the other constraints file (not -r minimum-constraints-install.txt).
We are running safety using these minimum constraints files so that when encountering a safety issue, we are forced to increase the minimum version. This is more stringent than using requirements files that specify versions with >=.
So when we run safety using the minimum-constraints.txt file, it turned out that safety ignores the -c minimum-constraints-install.txt line. (Note: Safety does understand lines such as -r minimum-constraints-install.txt within requirements files and then processes that file as if it was an included file).
This is a feature request to have safety support -c FILE within requirements files. It would not need to be aware that these are actually constraints; it would simply process -c FILE in a requirements file as an include file just like it already processes -r FILE.
We maintain minimum constraints files in our projects that define the minimum versions with == and are used with the
-coption of pip. That allows setting up a virtual Python env with exactly the minimum versions of the dependent packages in order to test against that minimum set of versions.Recently we started dividing the minimum-constraints files up into one with just the direct and indirect dependencies for installing our package, and one for everything, i.e. what is needed for development of the package and what is needed for installation.
In order to avoid duplicate maintenance of the dependencies for installation, we ended up with two minimum constraint files:
-cand then defines just direct and indirect dependencies for development.Pip understands this perfectly, but we must use
-c minimum-constraints-install.txtto include the other constraints file (not-r minimum-constraints-install.txt).Example: https://github.com/zhmcclient/python-zhmcclient/blob/master/minimum-constraints.txt
We are running safety using these minimum constraints files so that when encountering a safety issue, we are forced to increase the minimum version. This is more stringent than using requirements files that specify versions with
>=.So when we run safety using the minimum-constraints.txt file, it turned out that safety ignores the
-c minimum-constraints-install.txtline. (Note: Safety does understand lines such as-r minimum-constraints-install.txtwithin requirements files and then processes that file as if it was an included file).This is a feature request to have safety support
-c FILEwithin requirements files. It would not need to be aware that these are actually constraints; it would simply process-c FILEin a requirements file as an include file just like it already processes-r FILE.