Hello, Efraim Flashner <efr...@flashner.co.il> skribis:
> I still have a copy of the code on my machine but unfortunately it no > longer builds due to the constant churn of rust packages. > > One thing I remember explicitly about it was that building end packages > was faster than the current method, and that was before taking into > account reusing build artifacts. > > https://notabug.org/maximed/cargoless-rust-experiments Neat. > Another idea which I'm not in love with is what Debian does. They grab > all of the sources into one build environment and then build everything. > It simplifies the dependency management of the sources but for us it > would make it so that we can't touch anything in rust without causing a > full rebuild of everything. I believe this is also what Nixpkgs does, as discussed in this thread: https://toot.aquilenet.fr/@civodul/113532478383900515 I’m not a fan either. But I think one of the main criteria here should be long-term maintainability, which is influenced by internal design issues and by how we design our relation with the external packaging tool. By internal issues I mean things like #:cargo-inputs instead of regular inputs, which makes the whole thing hard to maintain and causes friction. (See <https://issues.guix.gnu.org/53127>.) As for the relation with Cargo and crates.io, the question is should we map packages one-to-one? Is it worth it? If the answer is yes, do we have the tools to maintain it in the long run. Ludo’.
