[bug#44492] [PATCH 01/52] gnu: Add rust-ruma-identifiers-validation-0.1.

[Leo Prikler]

Hello,

Am Mittwoch, den 24.02.2021, 12:46 +0100 schrieb Nicolas Goaziou:
> Hello,
> 
> Leo Prikler <leo.prikler@student.tugraz.at> writes:
> 
> > * gnu/packages/crates-io.scm (rust-ruma-identifiers-validation-
> > 0.1): New
> > variable.
> 
> Thank you! I have a few general comments about the patch set.
> 
> Nitpicks: some synopses end with a full stop, and most descriptions
> are
> not full sentences.
Indeed, for most of them I merely copied the output of `guix import
cargo`.  I was hoping a reviewer could help me find better synopses and
descriptions, as well as cross-check licenses.

> If you introduce a new version of an existing package, the old
> package
> should inherit from the new one.
I was afraid this would cause rebuilds for the existing package.  Was
that fear unfounded?

> More generally, I still think intermediate packages should use
> #:skip-build #t. Building them brings very little information, if
> any:
> 
> - A crate failing to build, for various reasons, is still correct as
> an
>   input to another crate
> - Even if all intermediate crates have "#:skip-build #t", building
> the
>   top-level crate locates accurately any missing Cargo input in the
>   dependency graph.
> 
> Not using #:skip-build, OTOH, costs a lot of resources and time for
> the
> CI, for users and developers.
I personally disagree.  The only reason a crate failing to build is a
"valid input" to another is because that other crate can decide to
completely disregard it, which sounds neither "reliable" nor
"efficient" for a programming language, that prides itself as both.

I will only skip builds for dead crates, i.e. crates I can reasonably
assume to only contain dead code due to their build failures.  This
does not seem to cost much when building dependant packages, as I've
found that in order to actually build the crates I have to explicitly
invoke `guix build <crate>`.

Of course, there's still the problem of CI.  Long-term, I think we
should find a way for this efficient programming language to reliably
produce reusable build artifacts.  Short term, hitting non-leaf
packages, that have cargo-build-system anywhere with a priority of
negative infinity sounds like a better workaround.  I want to be able
(as a developer) to explicitly build crates and determine where they
fail.

> Of course, this last remark is not specific to your patch set. I wish
> we
> can converge towards common Rust packaging guidelines.
I believe we should not cowtow to Rust and Cargo, but instead force
them to adhere to our principles; principles of building applications
*and* libraries reproducibly without encoding hashes in a huge ass-lock 
file.

Sorry for the off-topic rant.  Dealing with Rust for five days straight
has been somewhat damaging to my mental health, and to be very clear,
that is Rust's fault and not the fault of cargo-build-system.

Regards,
Leo