Add run_exports (take two)

conda-forge / graphviz-feedstock

A conda-smithy repository for graphviz.

BSD 3-Clause "New" or "Revised" License

5 stars 29 forks source link

Add run_exports (take two) #117

Closed traversaro closed 1 year ago

traversaro commented 1 year ago

graphviz is a C shared library that was also subject to migrations (see https://github.com/conda-forge/conda-forge-pinning-feedstock/pull/3457/files and https://github.com/conda-forge/conda-forge-pinning-feedstock/pull/3907), so it make sense to make sure that downstream packages depend correctly on it, to avoid problems such as https://github.com/conda-forge/gazebo-feedstock/issues/159 .

This is a new version of https://github.com/conda-forge/graphviz-feedstock/pull/111, has the fixes of the build (such as adding libwebp-base dependency) have already done.

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

conda-forge-webservices[bot] commented 1 year ago

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

traversaro commented 1 year ago

@conda-forge-admin, please rerender

github-actions[bot] commented 1 year ago

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you, but it looks like there was nothing to do.

This message was generated by GitHub actions workflow run https://github.com/conda-forge/graphviz-feedstock/actions/runs/3984712315.

jakirkham commented 1 year ago

Thanks for raising this Silvio!

One consideration is Graphviz is often used simply as command line tool. This can occur even with dependent packages. In those cases, it's not clear that adding a version constraint based on the library's ABI stability would be optimal.

Wonder if an improvement to this approach would be to split out the library portion (say as libgraphviz) from the command line portion. So that downstream dependencies that only care about the library (and preserving ABI compatibility with it) can do so.

Curious what others think

traversaro commented 1 year ago

Thanks for chiming in @jakirkham ! If splitting the package is problematic, a possible alternative to what you proposed (but similar in spirit) is to create an empty meta-package libgraphviz that depends on graphviz with exact version, but only adds run_exports. In this way, we have exactly the same packaging complexity, but downstream libraries that depend on graphviz as a library can explicitly specify that by depending on libgraphviz instead of graphviz.

nehaljwani commented 1 year ago

I support adding run_exports to graphviz.

But I need help in understanding how splitting the package helps with version constraints. I'm probably missing something very obvious here.

... as command line tool. This can occur even with dependent packages.

But won't these dependent packages specify graphviz only as a run dependency and therefore not be affected by run_exports, for example: pydot?

nehaljwani commented 1 year ago

Included this commit in #125