all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Hartmut Goebel <h.goebel@crazy-compilers.com>
To: Efraim Flashner <efraim@flashner.co.il>, guix-devel <guix-devel@gnu.org>
Cc: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Subject: Discussion: How to package rust crates now and in future?
Date: Fri, 18 Dec 2020 19:08:24 +0100	[thread overview]
Message-ID: <995a1d66-1c65-15fd-ea61-669e2160bc71@crazy-compilers.com> (raw)
In-Reply-To: <X9u62uXj6nEbuonK@E5400>

[-- Attachment #1: Type: text/plain, Size: 3760 bytes --]

Hi,

I suggest to discuss this with a broader community.

*TIL: Shall rust packages be packaged with #:skip-build #t? Shall tests 
be run for all crates?*
*My vote: skip-build #t, no tests*

Background: I just submitted some patches for some crates, setting 
#:skip-build for those I touched or added. My rational:

1) Building crate "libraries" is of no use. Rust still has no notion of 
"libraries", neither shared not static. it does not even provide any 
means to use "object"-files from another package. All crates will be 
build again and again for each package using it. And you will notice 
that the output of most crates will be almost empty (only exception: if 
the crate build a program).

2) This is what the crates importer does: It sets skip-build for all 
packages it imports as dependencies. It also does not add the 
crate-build-dependencies for these packages. (Please note that while I 
made the crates importer to honor semver versions, this has already been 
prepared in other patches and was not argued about.


Am 17.12.20 um 21:08 schrieb Efraim Flashner:
> I'm in favor of building the packages anyway, it serves as a check that
> the inputs are actually correct.

When I started packaging crates, I did this too. But then I learned, 
that others do not. So we should define how this should be handled in 
the future - and adjust the importer accordingly.

This might not be possible - as there is another issue in the Rust 
ecosystem: The language is still moving fast.

3) If some packages requires rustc 1.46, while our default rustc is 
still 1.40, we need to add rustc-1.46 as an input to this package and to 
many of it's dependents. (AFAIR the package will even depend on *both* 
version then.) Now if we move on to rustc 1.50, extra care has to be 
taken to remove these dependencies.

Even worse: All packages depending on such a package on will also depend 
on rustc 1.46, and all changes to rustc 1.46 will trigger a rebuild - 
without *any* use.

4) Since (2) building rust packages costs *a lot* of resources: time, 
memory and electrical power. As an example, building sequoia takes about 
20 Minutes on my machine. Most of the time is spend compiling 
dependencies of dependencies. And all these dependencies of dependencies 
will be compiled over and over again.

5) *If* we decide to build dependencies, we should restrict this to 
*one* build. This means: either not run the tests or only do a test 
build. The reason is: When running the tests, all the code, including 
the dependencies, is compiled again with some "test" flag set. This will 
add yet another huge amount of time, memory and electrical power.

To give you some figure: A release and test build for sequoia takes 
about 45 minutes on my machine, requiring 9 GB of space in /tmp. So this 
is double the time if the release build only.

I can't imaging how many hours it would take to rebuild sequoia is one 
of the lower level dependencies changes - which is quite often the case 
in rust.

6) This not only effect berlin, but also every user out there requiring 
a rebuild for some reason. This will lead to a very, very bad user 
experience - practically kicking out users with less powerful equipment.

7) Given the rushing climate crisis, we MUST NOT waste this gigantic 
amount of electrical power. We are in a position of huge impact. If we 
decide to save power, hundreds of Guix users will save power (and 
money). If we decide to waste power, this will multiply by the number of 
Guix users.

*It's our responsibility to protect the earth!**Yes to #:skip-build #t.*

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |


[-- Attachment #2: Type: text/html, Size: 5235 bytes --]

  reply	other threads:[~2020-12-18 18:10 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-16 20:31 [bug#45276] [PATCH 00/26] Update sequoia-opengpg to 1.0.0 Hartmut Goebel
2020-12-16 20:36 ` [bug#45276] [PATCH 01/26] gnu: Add rust-cipher-0.2 Hartmut Goebel
2020-12-16 20:36 ` [bug#45276] [PATCH 02/26] gnu: Add rust-cmac-0.5 Hartmut Goebel
2020-12-16 20:36 ` [bug#45276] [PATCH 03/26] gnu: Add rust-ctr-0.6 Hartmut Goebel
2020-12-16 20:36 ` [bug#45276] [PATCH 04/26] gnu: Add rust-dbl-0.3 Hartmut Goebel
2020-12-16 20:36 ` [bug#45276] [PATCH 05/26] gnu: Add rust-eax-0.3 Hartmut Goebel
2020-12-16 20:36 ` [bug#45276] [PATCH 06/26] gnu: Add rust-sha1collisiondetection-0.2 Hartmut Goebel
2020-12-16 20:36 ` [bug#45276] [PATCH 07/26] gnu: Add rust-crypto-mac-0.10 Hartmut Goebel
2020-12-16 20:36 ` [bug#45276] [PATCH 08/26] gnu: Add rust-pin-utils-0.1 Hartmut Goebel
2020-12-16 20:36 ` [bug#45276] [PATCH 09/26] gnu: Add rust-pin-project-1, rust-pin-project-internal-1 Hartmut Goebel
2020-12-16 20:36 ` [bug#45276] [PATCH 10/26] gnu: Replace rust-capnp-0.10 by rust-capnp-0.13 Hartmut Goebel
2020-12-16 20:36 ` [bug#45276] [PATCH 11/26] gnu: Replace rust-capnp-futures-0.10 by rust-capnp-futures-0.13 Hartmut Goebel
2020-12-16 20:36 ` [bug#45276] [PATCH 12/26] gnu: Replace rust-capnp-rpc-0.10 by rust-capnp-rpc-0.13 Hartmut Goebel
2020-12-16 20:36 ` [bug#45276] [PATCH 13/26] gnu: Replace rust-capnpc-0.10 by rust-capnpc-0.13 Hartmut Goebel
2020-12-16 20:36 ` [bug#45276] [PATCH 14/26] gnu: Replace rust-win-crypto-ng-0.2 by rust-win-crypto-ng-0.4 Hartmut Goebel
2020-12-16 20:36 ` [bug#45276] [PATCH 15/26] gnu: rust-proc-macro-hack-0.5: Update to 0.5.19 Hartmut Goebel
2020-12-16 20:36 ` [bug#45276] [PATCH 16/26] gnu: rust-socket2: Update to 0.3.18 Hartmut Goebel
2020-12-16 20:36 ` [bug#45276] [PATCH 17/26] gnu: rust-futures-util-0.3: Update to 0.3.8 Hartmut Goebel
2020-12-16 20:36 ` [bug#45276] [PATCH 18/26] gnu: rust-futures-0.3: " Hartmut Goebel
2020-12-16 20:36 ` [bug#45276] [PATCH 19/26] gnu: rust-futures-channel-0.3: " Hartmut Goebel
2020-12-16 20:36 ` [bug#45276] [PATCH 20/26] gnu: rust-futures-core-0.3: " Hartmut Goebel
2020-12-16 20:36 ` [bug#45276] [PATCH 21/26] gnu: rust-futures-executor-0.3: " Hartmut Goebel
2020-12-16 20:36 ` [bug#45276] [PATCH 22/26] gnu: rust-futures-io-0.3: " Hartmut Goebel
2020-12-16 20:36 ` [bug#45276] [PATCH 23/26] gnu: rust-futures-macro-0.3: " Hartmut Goebel
2020-12-16 20:36 ` [bug#45276] [PATCH 24/26] gnu: rust-futures-sink-0.3: " Hartmut Goebel
2020-12-16 20:36 ` [bug#45276] [PATCH 25/26] gnu: rust-futures-task-0.3: " Hartmut Goebel
2020-12-16 20:36 ` [bug#45276] [PATCH 26/26] gnu: sequoia: Update to 1.0.0 Hartmut Goebel
2020-12-17 15:01 ` [bug#45276] [PATCH 00/26] Update sequoia-opengpg " Nicolas Goaziou
2020-12-17 16:05   ` Hartmut Goebel
2020-12-17 20:08     ` Efraim Flashner
2020-12-18 18:08       ` Hartmut Goebel [this message]
2020-12-18 18:26         ` Discussion: How to package rust crates now and in future? John Soo
2021-01-02 12:53           ` Hartmut Goebel
2020-12-19  6:42         ` Pjotr Prins
2021-01-02 12:50           ` Hartmut Goebel
2021-01-06 18:05       ` [bug#45276] [PATCH 00/26] Update sequoia-opengpg to 1.0.0 Hartmut Goebel
2021-01-06 19:37         ` Leo Famulari
     [not found] ` <handler.45276.B.160815072411765.ack@debbugs.gnu.org>
2021-01-08  9:35   ` bug#45276: Acknowledgement ([PATCH 00/26] Update sequoia-opengpg to 1.0.0) Hartmut Goebel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=995a1d66-1c65-15fd-ea61-669e2160bc71@crazy-compilers.com \
    --to=h.goebel@crazy-compilers.com \
    --cc=efraim@flashner.co.il \
    --cc=guix-devel@gnu.org \
    --cc=mail@nicolasgoaziou.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.