conda-forge.github.io
conda-forge.github.io copied to clipboard
Any way to improve dependency checking?
Conda-forge documentation
- [X] I could not solve my problem using the conda-forge documentation.
Installed packages
N/A
Environment info
N/A
Issue
I like conda-forge, but I repeatedly find packages with dependencies that do not match the dependencies of their upstream packages. I file issues with the appropriate feedstock repo each time I find such a mismatch and sometimes fix the issues myself, but I've filed many such issues, and this doesn't seem like the best way to go about this.
If the feedstock are Python-based ones, you can improve this by:
- Ensure that they have a call to
pip checkin the test section. - A lot of projects should also be able to get automated dependency updates via grayskull. You can enable that by setting
bot: inspection: update-grayskullin theconda-forge.yml
If the feedstock are Python-based ones, you can improve this by:
1. Ensure that they have a call to `pip check` in the test section. 2. A lot of projects should also be able to get automated dependency updates via grayskull. You can enable that by setting `bot: inspection: update-grayskull` in the `conda-forge.yml`
Does the call to pip check need any parameters or anything, or just pip check?
Also, perhaps, is there a better way of making this known to feedstock developers / maintainers?
If the feedstock are Python-based ones, you can improve this by:
1. Ensure that they have a call to `pip check` in the test section. 2. A lot of projects should also be able to get automated dependency updates via grayskull. You can enable that by setting `bot: inspection: update-grayskull` in the `conda-forge.yml`Does the call to
pip checkneed any parameters or anything, or justpip check?
Just pip check.
I repeatedly find packages with dependencies that do not match the dependencies of their upstream packages
I would add that sometimes upstream has wrong dependencies / constraints (either incomplete, or way too strict). So automated solutions can only take you so far.
I would add that sometimes upstream has wrong dependencies / constraints (either incomplete, or way too strict). So automated solutions can only take you so far.
I have seen that, too. However, in my experience, it seems to be much more common the other way around. In general, I wonder if it's too easy for feedstock maintainers to just click through without actually doing any real verification of what may have changed, since dependency changes seem to be fairly common when releasing new versions.
In some case if the test suite of the python package is available, you can also run the test suite to eventually detect wrong dependencies/constraints reported upstream.