You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note that this somewhat means that every user who includes our libraries, including "Providers", will have cos-tool in their charm, when it's only actually invoked from "our" side (and written to verify that the binary is actually present, otherwise it skips).
Including cos-tool in this package in a "correct" way is an absolute dumpster fire due to what passes muster as best practice, and that's mostly because the wheel ecosystem rapidly becomes incoherent.
Even if it didn't, we would then need to trigger a workflow here when new cos-tool releases happen in order to re-build a wheel so there's a pre-baked binary in PyPi, and if there's not, we're faced with either a failed wheel build and telling them to package Go or trying to fetch the Go installer from the Python package manifest and doing it there (which we'd probably have to do anyway, because I don't think we have any way to hint to charmcraft via pydeps that "hey, to pack this charm, you also need Go v1.XX for some reason!").
The "users" who need to download cos-tool are actually just us, since we are the only ones who actually execute it. When/if anyone else wants to, and it's worth the time investment to jump through PyPi's hoops, then sure, but in the meantime, documenting the 10 lines they need to add is honestly more reliable.
Currently users need to download cos-tool as part of build and before testing.
The text was updated successfully, but these errors were encountered: