Re: Building hexyl (a rust app) without cargo, with antioxidant-build-system

[raingloom <raingloom@riseup.net>]

On Mon, 04 Apr 2022 11:26:45 +0200
Maxime Devos <maximedevos@telenet.be> 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.)