On Mon, 04 Apr 2022 11:26:45 +0200 Maxime Devos <[email protected]> wrote:
> Brendan Tildesley schreef op ma 04-04-2022 om 15:10 [+1000]: > > I would have called it cargone. > > > > Do you believe sidestepping cargo all together like this is a good > > long term strategy? In particular that importing packages will > > still be easy. > > The package definitions look almost the same, except for: > > * #:cargo-inputs and #:cargo-development-inputs are moved to > 'inputs'/'propagated-inputs' and 'native-inputs' > * For a few packages, #:features ~'(...) needs to be added > * antioxidant-build-system doesn't look at version numbers, > so the numbers of variants of packages that needs to be defined > could perhaps be reduced > * Cycles are not supported > > The fourth point might make things difficult though I have some ideas > on how to resolve it (without simply disabling tests) (TBI!). > Otherwise, I don't see much complications with importing packages. > > Greetings, > Maxime. I'm also a bit worried with the trend of Guix trying to duplicate functionality already present in language package managers and config file formats. It creates a two-sources-of-truth situation. Trying to keep one up to date with the other can be an issue, this is why I didn't create a custom record type for Yggdrasil config files and just used a generic JSON converter. Which paid off, since there were in fact changes in the config fields between versions. Will this build system avoid that issue as well? I guess if the data it operates on has truly stable semantics, then writing an independent implementation is not as big a problem, since once written and debugged, it won't need to change. (And getting rid of cargo would be nice for Rust dev on Guix.)
