Closed PyDeps closed 1 year ago
Hi @PyDeps
The requirements.txt
(AKA constraint file) is for dependabot only.
The real dependency is defined in setup.cfg
when users install this Python library. Do you still think it is too strict?
Just wondering out loud here (so to speak). Having spent a lot of time looking through source code of several Ansible core and community repos lately, I've also noticed these differences between specified versions in multiple files in the same repo.
If something odd like this is being done on purpose ("for dependabot only", in this case), wouldn't documenting this prominently in the files themselves make the intention more clear and reduce situations where well-intentioned contributors invest a lot of time, possibly needlessly?
Could the requirements.txt
and/or setup.py
files be generated from a single source using a helper Makefile
? That would be both more DRY and more clear about programmer intentions. Or a request to GitHub to support dependabot
reading setup.py
instead of only requirements.txt
? An explanation in a comment to a PR or Issue is not really the ideal place for documenting source code.
Sorry to make you confused.
If something odd like this is being done on purpose ("for dependabot only", in this case), wouldn't documenting this prominently in the files themselves
It is self-explanatory at the top of requirements.txt
. I thought you may miss it.
The requirements.txt
is generated by setup.cfg
Could the requirements.txt and/or setup.py files be generated from a single source using a helper Makefile?
No setup.py
in this repo.
Or a request to GitHub to support dependabot reading setup.py instead of only requirements.txt?
Supporting setup.py
may not be a good way. Please refer to https://github.com/dependabot/dependabot-core/issues/3290#issuecomment-1289814612
No, I'm sorry. You did not confuse me. I only responded to the comment thread (without taking the additional time to look at the actual file) and thus I did miss (as you point out) the comment about auto-generation.
Hi, In molecule, inappropriate dependency versioning constraints can cause risks.
Below are the dependencies and version constraints that the project is using
The version constraint == will introduce the risk of dependency conflicts because the scope of dependencies is too strict. The version constraint No Upper Bound and * will introduce the risk of the missing API Error because the latest version of the dependencies may remove some APIs.
After further analysis, in this project, The version constraint of dependency ansible-compat can be changed to >=0.2.0,<=2.2.1. The version constraint of dependency cookiecutter can be changed to >=0.5,<=2.1.1. The version constraint of dependency enrich can be changed to >=1.1,<=1.2.7. The version constraint of dependency jsonschema can be changed to >=2.0.0,<=4.6.0. The version constraint of dependency pluggy can be changed to >=0.3.0,<=1.0.0.dev0. The version constraint of dependency rich can be changed to >=0.2.0,<=12.6.0a2.
The above modification suggestions can reduce the dependency conflicts as much as possible, and introduce the latest version as much as possible without calling Error in the projects.
The invocation of the current project includes all the following methods.
The calling methods from the ansible-compat
The calling methods from the cookiecutter
The calling methods from the enrich
The calling methods from the jsonschema
The calling methods from the pluggy
The calling methods from the rich
The calling methods from the all methods
@developer Could please help me check this issue? May I pull a request to fix it? Thank you very much.