Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature] Eliminate Hidden Dependencies #10217

Open
1 task done
jsallay opened this issue Dec 20, 2021 · 2 comments
Open
1 task done

[feature] Eliminate Hidden Dependencies #10217

jsallay opened this issue Dec 20, 2021 · 2 comments

Comments

@jsallay
Copy link
Contributor

jsallay commented Dec 20, 2021

One of the things I like most about Conan is that dependencies and versions are explicitly stated in the recipe. This makes it really easy to hand off a recipe to someone else and have confidence that they can build it too.

The big exception to this are many of the fundamental build requirements. Most all of the recipes that I have looked at in conan center have build requirements that are not in the recipe. For example, the recipe for yaml-cpp, https://conan.io/center/yaml-cpp?tab=recipe, requires cmake to build but it is not included as a build requires. It appears that the expectation is that either a profile is used that specifies a cmake version or a system installed version is already present on the system. No information is present in the recipe about compatible cmake versions.

I ran into a problem where my project needs a more recent version of cmake than what is available in the system repos. So a user must either build a newer version from source or use a profile with an adequate (but undocumented) version of cmake.

I understand some of the reasons for not wanting to include these tools in the recipes. It would be annoying to have to update every the versions of cmake, make, etc in every single recipe every time that a new version comes out and would lead to version conflicts when some recipes are updated and others aren't.

Proposal

I would propose a simple addition to the profile files that I believe can simplify the use and management of these requirements. A new section could be introduced called [package_versions]. Much like the build requirements section, the user could specify packages and versions to use. The key difference would be that the package versions listed would only be used if a recipe included it.
For example

[build_requires]
cmake/3.21.4

Make cmake a requirement of all packages built with this profile, which can lead to circular dependencies (cmake depends on openssl which now thinks that it depends on cmake if I use this profile).
This could be replaced with:

[package_versions]
cmake/3.21.4

The desired behavior would be that only packages that have a requires or build_requires of cmake will be overrided to use this version. Thus yaml-cpp, could include cmake as a dependency in its conanfile.py, and would use the specified version when built with our profile. openssl, on the other hand, would not contain cmake as a dependency and would not be impacted.

With this feature in place, it would be desirable to update recipes to include their dependencies on cmake, make, meson, etc. I believe that this would be good, because the recipes would be explicit about all of the dependencies used, thus making them more portable. This feature could be quite powerful when coupled with the compatible_packages feature to make it easy to check that the versions specified in the profile is compatible with all of the packages.

@memsharded
Copy link
Member

Hi @jsallay

I think you are going to like this ongoing work: #10166 😄

It is a very preliminary idea, but I think it is pretty aligned with what you are suggesting here.

@jsallay
Copy link
Contributor Author

jsallay commented Dec 21, 2021

That looks great. Does it differ significantly from what I proposed (either removing or adding features)? I don't have significant amounts of time, but I could probably contribute some to this. If nothing else, I would be happy to test it out and provide feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants