Unpin requirements #71
Conversation
|
Hi @adamchainz. Thank you for your contribution :-) Can you rebase your branch with the last version on master. I made a change to run GitHub actions on PR also. I had thought about fixing the dependencies or not in the past. I preferred to fix them to avoid surprises when installing the grapher. Not sure at this time that minor dependency changes don't break the grapher :-/ This is one of the reason that dependabot is enabled on the project. |
lxml has a security release in version 4.6.3, however I cannot upgrade to it due to ansible-playbook-grapher pinning it directly. As an installable tool that can interact with a virtualenv, ansible-playbook-grapher should not pin dependencies but declare ranges up until the next backwards-incompatible version, to allow users to fetch such upgrades.
adamchainz
force-pushed
the
unpin_requirements
branch
from
09f1108
to
0984058
Compare
|
I don't pin requirements on any of the 30 open source projects I maintain and it is basically never a problem. Most packages are pretty stable in Python. And anyway, users should be pinning their requirements so they can find and report any incompatibilities to you. I do pin requirements in my projects' test runs though, and upgrade them every 2 weeks. This gives me repeatable builds and means I catch any necessary changes soon enough. |
|
You are right |
lxml has a security release in version 4.6.3, however I cannot upgrade to it due to ansible-playbook-grapher pinning it directly. As an installable tool that can interact with a virtualenv, ansible-playbook-grapher should not pin dependencies but declare ranges up until the next backwards-incompatible version, to allow users to fetch such upgrades.