A recent tempest brought up question I don’t see handled anywhere, though of course I’m not diligent enough to have searched the whole world’s data: chardet 7.0 changed licensing after a rewrite (this post is not to comment on the merits of the change!). Dependency projects sometimes undergo “political” changes that can have a broader impact than a single consuming project. Let’s say hypothetical project foo changed their license from bar to baz. Now let’s say a given company’s lawyers decree that baz is unacceptable for any use within the company, but they can continue to use bar-licensed versions. Is there a way to say, on a wider basis than a a given project’s requirements, that one shall not update to the baz-licensed version, even if running in a non-global pip (i.e., in a virtualenv)? That is, is there benefit to supporting version constraints (prohibitions?) in pip configuration files, as opposed to leaving it to requirements/pyproject?
I guess potentially this is not completely different than the post on blocking policy-violating downloads
All pip options can be specified via CLI, env var, or config, so you should be able to add:
pip config set global.constraint /home/youruser/.pip/constraints.txt
A couple of things though:
- I don’t think this is well tested workflow (I haven’t tested it)
- It will be overridden the a CLI level option
--constraintso if providing at the CLI level you must provide both your project constraints and your global constraints.
FWIW, I tried as an expierment and it does seem to work out - the constraint file was read and correctly acted on when running a virtualenv pip.
I think that, typically the answer for this whole range of questions is: setup and curate your own Python package index. I think there are Python package index implementations around that allow the kind of flexibility where, for example, they can act as some kind of proxy with custom filtering rules. In this case such a filtering rule would be “allow chardet from PyPI but only versions 6 and lower”.