Am Montag, den 31.05.2021, 19:47 +0200 schrieb Pjotr Prins: > On Sun, May 30, 2021 at 09:17:20PM +0200, Konrad Hinsen wrote: > > How about pushing all the other package manager towards producing > > sexp-packs, and helping them to get there? > > I have a feeling they won't be that interested ;). I do think some of them are interested, but you're right in that the industry as a whole is not.
> My thoughts are that every software package simply consists of files > that need to be compiled (if not interpreted) and be copied in place. That is the case, but surely you aren't suggesting to implement all build systems in terms of copy-build-system, right? :P > As Guix takes care of the first and the last - the issue centers > around building. The idea is to dress down these language specific > builders, such as cargo, so you don't have all the included > complexity. The thing with complex systems is that you will still have complexity no matter how you look at them and cargo is such a system. The only way to not see that complexity is to ignore it because your build succeeds, and I'm sure Rust, npm, etc. users (read: victims) are physically trained to clear their mind from such heathen thought. > A sexp-pack would represent the most simple build instructions to > build a package on its own. Now, of course the current guix-builders > solve that too. But, what I am proposing is to split out the actual > build step into a package definition, so as to present something > simpler to Guix. I don't think this would be simpler to Guix, you'd just create even more packages, that actually aren't usable. > I found a cargo -> ninja converter. It is that kind of idea. Guix > would use ninja with rustc instead of cargo. A stripped down cargo > could potentially work too - but cargo is a complex beast. The problem with rust+cargo is not just that cargo isn't make or ninja (although that is certainly a part of it), it is also that any make/ninja port would have to somehow take care of all the other things that cargo does. It doesn't shake the ginormous dependency trees for example. This is not to say, that rustc+ninja is not worth pursuing. If the output of rustc+ninja had some nice property, e.g. it was a shared library, that could be reused, we might still want to rewrite rust- build-system in terms of it. In a similar manner, Guix people are currently looking towards Rome to perhaps simplify node-build-system or erect a new build system next to it. Small rant w.r.t. #:skip-build?, this flag is a hack and everyone involved knows it and we ought to find a way to actually build rust crates in a manner that doesn't require complete source closure for the next rust-thingy to use it. > A simplified build step would make it easier to troubleshoot these > packages. I think I'd personally rather deal with the output of make or ninja over that provided by rust/cargo 9 times out of 10 if that is what you're going for, but different strokes for different folks. We don't want to alienate all the people actually using Rust on Guix by taking away their favourite error message :P Regards, Leo
