-
Notifications
You must be signed in to change notification settings - Fork 73
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
Unable to build multi-base subordinate charms on 24.04 #1789
Comments
Yes, I have discussed this with @sergiusens and briefly with @niemeyer. The current design isn't set in stone, and Sergio is going to have a bit of a think about what alternatives may look like. For the sake of transparency, one area that could be quite problematic for "multi-base" charms is where many Python libraries have transitioned to building certain parts of their CPython code with Rust - this is increasingly popular ( The issue is not that the code is built in Rust, but rather that more and more core Python libraries are including dynamically-linked object files, where we could see incompatibilities across LTS versions of Ubuntu. The current design indeed means that you must have one I definitely think we should investigate this, even if we do in fact end up with one artefact per base, we might be able to ease the developer experience slightly - and perhaps even introduce a |
For the reader, the proposed new syntax is: name: some-charm
type: charm
# Here is the biggest difference - a single base per charmcraft.yaml
base: ubuntu@22.04
platforms:
amd64:
arm64:
armhf:
# ... |
FYI, we already have this problem (and we already need to build on the same Ubuntu base that we're running on) Here are the wheels that are affected just for MySQL Router:
Here are some other wheels used by our other charms that are specific to minor python version:
|
Python requirements are specified outside of |
If we're talking about incompatibilities of versions, poetry already handles that for us. When creating poetry.lock, poetry respects syntax (in our direct & indirect dependencies) that specifies different versions (or different dependencies entirely) across different python versions and different architectures. The poetry.lock file resolves dependencies for each python version & architecture into poetry.lock (or will raise an error telling you what is incompatible). When we export requirements.txt from poetry.lock, this requirements.txt contains resolved dependencies for each python version & architecture But I think we might be talking about incompatibilities of wheels/virtual environments across bases—e.g. a pyyaml wheel built on ubuntu 20.04 (python 3.8) will not work on 22.04 (python 3.10). By building on the same base that we run on (with charmcraft), we are no longer concerned about these incompatibilities |
Yes, indeed - that is what I'm referring to here 🙂 |
What are we doing to prevent code duplication with this change? The naive next step for charmers will be keeping one branch or charm directory per base (since charmcraft doesn't cater to multiple charmcraft files in one dir). That's a lot of code duplication we're forcing them to handle. The issue is a bit worse for libraries too, where its unclear which instance of the code owns the library. If we're requiring a different charmcraft.yaml per base, charmcraft should make that easy to administer. |
That's precisely the problem I'm working to solve with @sergiusens and @niemeyer - though we've not yet reached any conclusion. To be continued :) |
With having a different |
Thank you for reporting us your feedback! The internal ticket has been created: https://warthogs.atlassian.net/browse/CRAFT-3481.
|
Is there any update on this issue? |
For anyone who, like me, did not feel that it was clear how to use these new constructs, see the core24 reference in the following article from the snapcraft docs. However, as of right now, |
Bug Description
Subordinate charms use the base of the principal charm. Therefore, subordinate charms such as MySQL Router need to support multiple bases, since we can't enforce the principal charm to use a particular base. Currently MySQL Router supports 20.04 and 22.04 and plans to support 24.04.
However, with the new
base
andplatforms
syntax in charmcraft 3, it is not possible to build a subordinate charm on 20.04, 22.04, and 24.04 with a single charmcraft.yaml and git branchAdditional context:
I believe @jnsgruk and @sergiusens were/are discussing this. Created an issue to track officially per @taurus-forever's request
To Reproduce
Environment
Ubuntu 22.04
charmcraft.yaml
Relevant log output
The text was updated successfully, but these errors were encountered: