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

* gnu/packages/crates-io.scm (rust-ruma-identifiers-validation-0.1): New
variable.
---
 gnu/packages/crates-io.scm | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

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.

If you introduce a new version of an existing package, the old package
should inherit from the new one.

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.

Of course, this last remark is not specific to your patch set. I wish we
can converge towards common Rust packaging guidelines.

Regards,

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

Leo Prikler <leo.prikler@student.tugraz.at> writes:

> I was afraid this would cause rebuilds for the existing package. Was
> that fear unfounded?

I don't think it would change anything. It is what we usually do in
"crates-io.scm".

> 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.

Probably, but the problem at hand is not to fix how Rust builds its
crates, but rather optimize Rust packaging.

> 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>`.

There's much more work involved. You have to take care of development
inputs which increases drastically the number of crates to package.
Moreover, you need to try building each of them, which takes time. Not
skipping builds makes de facto some packages impossible to package.

> 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.

As a packager, you don't need to build the crate to fix any issue
arising at a higher level, as I pointed out already. If you're
developing the crate, that's another story. But then, you can quickly
write your own package definition.

I think the real questions about building intermediate crates, from
a packager point of view, are:
- does that make the packages reproducible?
- does that make the packages more secure?
- does that make the packages easier to define?

From my experience, the answer is "no" to any of these. This is a net
loss.

> 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.

I don't think it is worth focusing of this. We currently do a good job
in Rust packaging, really. But it doesn't make much sense to have some
packages skipping builds and not some others.

What saddens me a bit is that individuals (including me, of course) are
currently doing as they see fit, but we haven't so far decided, as
a group, how to deal with the question uniformly. I hope we can converge
quickly.


Regards,

Am Mittwoch, den 24.02.2021, 16:41 +0100 schrieb Nicolas Goaziou:
> Leo Prikler <leo.prikler@student.tugraz.at> writes:
> 
> > I was afraid this would cause rebuilds for the existing package.
> > Was
> > that fear unfounded?
> 
> I don't think it would change anything. It is what we usually do in
> "crates-io.scm".

Fair enough, I'll do so when I get to it.

> > 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.
> 
> Probably, but the problem at hand is not to fix how Rust builds its
> crates, but rather optimize Rust packaging.

I think those two issues are related, but that's a discussion for guix-
devel.  So is the rest of this, but I might as well make my case here.

> > 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>`.
> 
> There's much more work involved. You have to take care of development
> inputs which increases drastically the number of crates to package.
> Moreover, you need to try building each of them, which takes time.
> Not
> skipping builds makes de facto some packages impossible to package.

We could work developer inputs into the recursive importer, that should
not be an issue.

Honestly, it is a greater waste of time to recompile every dependency,
have the build fail, change some minor thing in the package and
recompile everything again.  Yes, `guix build -K` helps to an extent,
but it doesn't help if I made a typo in my build phase and got a guile
backtrace.

If cargo inputs worked like normal inputs, they'd be built reliably
once and no time would be wasted rebuilding them over and over in any
packages using them.

> > 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.
> 
> As a packager, you don't need to build the crate to fix any issue
> arising at a higher level, as I pointed out already. If you're
> developing the crate, that's another story. But then, you can quickly
> write your own package definition.

Maybe there'd be an argument if we had --no-skip-build, but I think
we're working our way backwards here; trying work around a workaround.

> I think the real questions about building intermediate crates, from
> a packager point of view, are:
> - does that make the packages reproducible?
> - does that make the packages more secure?
> - does that make the packages easier to define?
> 
> From my experience, the answer is "no" to any of these. This is a net
> loss.
I don't think there is any influence on the ease of definition, since
either one would be handled by the recursive importer.  The difficulty
for packagers currently would be to manually undo the automatic build
skipping done through the importer.

As for reproducibility/security, there is yet little to gain, because
the leaf crate can simply ignore its inputs and do whatever, but if we
built the crates ahead of time, and disallowed the automatic building
of dependencies, we would get efficient *and* reproducible Rust
packages.

Another thing that bugs me as a packager is that cargo inputs don't
work for `guix refresh`, so I can't even be sure whether to put my
patch to master or core-updates.

> > 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.
> 
> I don't think it is worth focusing of this. We currently do a good
> job
> in Rust packaging, really. But it doesn't make much sense to have
> some
> packages skipping builds and not some others.
If skipping only some builds is not an option, you are either left with
skipping all builds or skipping none, one of which is certainly silly.

> What saddens me a bit is that individuals (including me, of course)
> are
> currently doing as they see fit, but we haven't so far decided, as
> a group, how to deal with the question uniformly. I hope we can
> converge
> quickly.
I personally hope that some of the issues resulting from this "wild
west" approach to packaging will be alleviated by #46399.  Having
crates as regular inputs also increases the value of #:skip-build? #f.

Regards,
Leo

I'll send the revised patches in batches of size 10, so as to not cause too many
trouble to mailservers around the world.

Leo Prikler (52):
  gnu: Add rust-ruma-identifiers-validation-0.1.
  gnu: Add rust-ruma-identifiers-macros-0.17.
  gnu: Add rust-ruma-identifiers-0.17.
  gnu: Add rust-entities-1.
  gnu: Add rust-twoway-0.2.
  gnu: Add rust-unicode-categories-0.1.
  gnu: Add rust-comrak-0.7.
  gnu: Add rust-fragile-1.
  gnu: rust-either-1: Update to 1.6.1.
  gnu: Add rust-gspell-sys-0.4.
  gnu: Add rust-gspell-0.4.
  gnu: Add rust-muldiv-0.2.
  gnu: Add rust-gstreamer-sys-0.8.
  gnu: Add rust-gstreamer-0.15.
  gnu: Add rust-gstreamer-base-sys-0.8.
  gnu: Add rust-gstreamer-video-sys-0.8.
  gnu: Add rust-gstreamer-player-sys-0.8.
  gnu: Add rust-gstreamer-base-0.15.
  gnu: Add rust-gstreamer-video-0.15.
  gnu: Add rust-gstreamer-player-0.15.
  gnu: Add rust-gstreamer-audio-sys-0.8.
  gnu: Add rust-gstreamer-pbutils-sys-0.8.
  gnu: Add rust-gstreamer-pbutils-0.15.
  gnu: Add rust-markup5ever-rcdom-0.1.
  gnu: Add rust-ammonia-3.
  gnu: Add rust-html2pango-0.3.
  gnu: Add rust-pangocairo-sys-0.11.
  gnu: Add rust-pangocairo-0.10.
  gnu: Add rust-letter-avatar-1.
  gnu: Add rust-libhandy-sys-0.5.
  gnu: Add rust-libhandy-0.5.
  gnu: Add rust-loggerv-0.7.
  gnu: Add rust-lmdb-sys-0.8.
  gnu: Add rust-lmdb-0.8.
  gnu: Add rust-mdl-1.
  gnu: Add rust-aes-soft-0.6.
  gnu: Add rust-aesni-0.10.
  gnu: Add rust-aes-0.6.
  gnu: Add rust-block-modes-0.7.
  gnu: Add rust-hmac-0.10.
  gnu: Add rust-hkdf-0.10.
  gnu: Add rust-dbus-0.2.
  gnu: Add rust-secret-service-1.
  gnu: Add rust-atk-sys-0.10.
  gnu: Add rust-atk-0.9.
  gnu: Add rust-gtk-sys-0.10.
  gnu: Add rust-gtk-0.9.
  gnu: Add rust-sourceview4-sys-0.2.
  gnu: Add rust-sourceview4-0.2.
  gnu: Add rust-sourceview4-for-fractal.
  gnu: Add rust-letter-avatar-for-fractal.
  gnu: Add fractal.

 gnu/local.mk                                  |    2 +
 gnu/packages/crates-gtk.scm                   | 1527 +++++++++++++++--
 gnu/packages/crates-io.scm                    |  613 ++++++-
 gnu/packages/gnome.scm                        |  142 +-
 ...ractal-switch-from-failure-to-anyhow.patch |  143 ++
 .../rust-comrak-0.7-rustsec-2021-0026.patch   |   41 +
 6 files changed, 2318 insertions(+), 150 deletions(-)
 create mode 100644 gnu/packages/patches/fractal-switch-from-failure-to-anyhow.patch
 create mode 100644 gnu/packages/patches/rust-comrak-0.7-rustsec-2021-0026.patch

--
2.30.1