Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
igraphhas a run_exports that knows about its compatibility:https://github.com/conda-forge/igraph-feedstock/blob/main/recipe/meta.yaml#L18-L19
So we should move this to the
hostsection and this will meanigraphis automatically also included as a run dependency with the appropriate constraint.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another note here:
python-igraph0.10.x/0.11.x will NOT work with arbitraryigraphversions. If simply sayingigraph >=0.10,<0.11makes it possible for people to end up with an olderigraphand a newerpython-igraph, that WILL mess things up.The options are:
igraph(not a range!) for each specific version ofpython-igraphThis will be a little bit cleaner starting with igraph 1.x in that each python-igraph version should be compatible with an entire minor version range of igraph. However, in practice, there is likely not going to be more than one minor version in each series, unless we find a critical bug that needs immediate fixing. So in practice not much changes: each python-igraph version will be compatible with one igraph version.
Still, the intention is to be more rigorous about compatibility with the 1.x series, so I'd recommend using dynamic linking only for the 1.x series.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@szhorvat, the
run_exportsfromigraphitself will prevent this. My suggested approach would be that we restrict which version ofigraphis allowed at build time and the version at runtime will be restricted to be newer than or equal to that version, and less that the next minor version (because of thex.xin therun_exports). If that is not correct, we should fix therun_exportsinigraphitself.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could do this but it would require ignoring the
run_exportsfromigraph, which currently allow newer patch versions ofigraphat runtime than were used a build time.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@szhorvat, I believe I have added this in 1bd16f8. I used the version associated with the submodule that is used to vendor
igraphinpython-igraph0.11.9.