From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 24 08:13:37 2021 Received: (at 44492) by debbugs.gnu.org; 24 Feb 2021 13:13:37 +0000 Received: from localhost ([127.0.0.1]:33862 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEtyz-0001Nl-7A for submit@debbugs.gnu.org; Wed, 24 Feb 2021 08:13:37 -0500 Received: from mailrelay.tugraz.at ([129.27.2.202]:16009) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEtyw-0001Nb-C0 for 44492@debbugs.gnu.org; Wed, 24 Feb 2021 08:13:35 -0500 Received: from nijino.local (217-149-164-20.nat.highway.telekom.at [217.149.164.20]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4DlxF66V7Vz1LBRt; Wed, 24 Feb 2021 14:13:30 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4DlxF66V7Vz1LBRt DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1614172411; bh=8e9Y6bX8Vh0tWDe8MBMk9eKklZbO8PhT4oALsue3iEk=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=P94rbC/bZlb9e/KWVVA/e/yrylcEKsnKxrHYqX54fwNTA6ogv3pL1Lt0aU/b0ZkGk qTQPX0gjPecZWNKBUgBhEdiAwadi2985QMaZItc6K9+F/s62BHhbvbxxQQh6eSQybM Uspi9TQ1DZyPKYVygO6wZ5fLg9NjQ02iWXBoaeE0= Message-ID: Subject: Re: [bug#44492] [PATCH 01/52] gnu: Add rust-ruma-identifiers-validation-0.1. From: Leo Prikler To: Nicolas Goaziou Date: Wed, 24 Feb 2021 14:13:29 +0100 In-Reply-To: <87sg5lhemw.fsf@nicolasgoaziou.fr> References: <87tuu2p37n.fsf@cbaines.net> <20210224111135.28883-1-leo.prikler@student.tugraz.at> <87sg5lhemw.fsf@nicolasgoaziou.fr> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.116 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44492 Cc: 44492@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hello, Am Mittwoch, den 24.02.2021, 12:46 +0100 schrieb Nicolas Goaziou: > Hello, > > Leo Prikler 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 `. 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