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

fix self.info.clear() for python_requires and tool_requires #15285

Merged
merged 1 commit into from
Dec 18, 2023

Conversation

memsharded
Copy link
Member

@memsharded memsharded commented Dec 16, 2023

Changelog: Bugfix: Make self.info.clear() and header-only packages to remove python_requires and tool_requires.
Docs: conan-io/docs#3485

@memsharded memsharded added this to the 2.0.15 milestone Dec 16, 2023
Copy link
Member

@AbrilRBS AbrilRBS left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😶

@SSE4
Copy link
Contributor

SSE4 commented Dec 17, 2023

might it be a breaking change? seems like it can change package ID for existing recipes and packages

@memsharded
Copy link
Member Author

might it be a breaking change? seems like it can change package ID for existing recipes and packages

Might be changing some package-ids, but it is a bug, and can be fixed, even if that is the case.

However, it is unlikely to hit, and this is the reason it hasn't been detected so far:

  • It requires a header-only to use python-requires, which by the simple nature of header-only libs, is very uncommon
  • It requires a header-only to use tool-requires (more likely but still unusual, just maybe when it comes injected from the profile), but also changing the package build_mode, which is even more unlikely

@SSE4
Copy link
Contributor

SSE4 commented Dec 18, 2023

I read a stability commitment documentation, and it's kinda unclear:

Moving forward to following minor versions 2.1, 2.2, …, 2.X should never break existing recipes, packages or command line flows
If something is breaking, it will be considered a regression and reverted.
Bug fixes will not be considered breaking, recipes and packages relying on the incorrect behavior of such bugs will be considered already broken.

so I see, if you consider some behavior buggy (retrospectively or retroactively), you are always free to change it, and it's not breaking (that gives pretty much freedom to break things, actually).
about self.info.clear() in particular, right now it's not fully clear for reader, because docs never actually explain an effect on self.python_requires.
relevant paragraphs I found only say:

We have a package_id() method calling self.info.clear(). This is internally removing the settings from the package ID calculation so we generate only one configuration for our header-only library.
 For that case, there’s a simplified way of declaring that the generated package ID should not take into account settings, options or any information from the requirement which is using the self.info.clear() method inside another recipe method called package_id()

so doc mainly talks about settings and options.
at very least, documentation should be much more explicit on what does self.info.settings.clear actually do.

@memsharded
Copy link
Member Author

Bug fixes will not be considered breaking.

This is a clear bug. self.info.clear() should completely clear the info, this was always the intent, the expected behavior, and even the automatic implements relies on it. In the docs it says "or any information from the requirement", that might need some clarification, but that is the intended meaning of that sentence.

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

Successfully merging this pull request may close these issues.

4 participants