From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id zjyQCPpJQmLZNwAAgWs5BA (envelope-from ) for ; Tue, 29 Mar 2022 01:51:22 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id yDpSAPpJQmLzYwAAG6o9tA (envelope-from ) for ; Tue, 29 Mar 2022 01:51:22 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 8BDA321E03 for ; Tue, 29 Mar 2022 01:51:21 +0200 (CEST) Received: from localhost ([::1]:47938 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nYz8q-0006Tf-D0 for larch@yhetil.org; Mon, 28 Mar 2022 19:51:20 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48414) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nYz8P-0006T9-T2 for guix-devel@gnu.org; Mon, 28 Mar 2022 19:50:56 -0400 Received: from [2001:67c:2050::465:101] (port=47710 helo=mout-p-101.mailbox.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1nYz8M-0000cF-Rz for guix-devel@gnu.org; Mon, 28 Mar 2022 19:50:53 -0400 Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:105:465:1:4:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4KS8b342Lgz9sSN; Tue, 29 Mar 2022 01:50:39 +0200 (CEST) Content-Type: multipart/alternative; boundary="------------iFPw8I5kUdkOXOqZnomyLJ01" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brendan.scot; s=MBO0001; t=1648511437; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=Wj5a2mj8uvvrXn7RqQys5S0brKU9XcgvnCTCvGTLXB0=; b=bzMKAgx3EJ3MnA7ee4DdzYon7FIJ/y9l109XCBO97lRCMmvlx6Dx4Bwcf8MIM7USKpqxtL AXi9h/eBtVYcoMO0Wg6OLiHdIWlEQcPV2YUxhOa0EmU+Jxdea3VadRarcUIJ70i56uwZVt PyT6RPxIv48gRy/VSD+i3tbLRSWHyHbzEwv518Gk+UAU3plasuj9O9hLwxKSSitRvTzP+F 1XBPX1YPK14ZkjVxGwLJVbqFr/DDdSpc36GfeYRzIRKbZVGEWpDPath31nGZPZUyLZJDeW 2/cSuoASE/BvzjorAlnfstRfCvmzCmWJKiYaSb2Bc2nCKhCiEFmN6TadzlxDRg== Message-ID: Date: Tue, 29 Mar 2022 10:50:27 +1100 MIME-Version: 1.0 Subject: Improving importers best investment for growing gnu/packages/ Content-Language: en-US To: guix-devel@gnu.org, Maxime Devos , John Soo References: From: Brendan Tildesley In-Reply-To: X-Host-Lookup-Failed: Reverse DNS lookup failed for 2001:67c:2050::465:101 (failed) Received-SPF: pass client-ip=2001:67c:2050::465:101; envelope-from=mail@brendan.scot; helo=mout-p-101.mailbox.org X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: mail@brendan.scot Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1648511481; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=Wj5a2mj8uvvrXn7RqQys5S0brKU9XcgvnCTCvGTLXB0=; b=Vz/1JPrN8BvR31jPDWbEoGnNYS/PK+zF1jA5+P4FIT3VBgWwCvfCzmXQm6Wjjd01AXR+bj JUr8j3S5r7lsS5WlFpF+J4O9poVl7PH53r66F53SoaAbdApcM7Ko9loI6MLoyiQ5tZ+9F0 WnA3WjTA3xldFrICRKm9jEFC3ipg1+preg7Qv295RSOCNeDzFTAjcEK6su2EBYagFfnPXU 1W9A8RJRMEqREHzFS5jOmTd3auD6595vJbFY70dRgxi5uOsjuDpPHNYJPFZb/o5JjV4D4C mI4pOpH6lzLv0kY3/XE9an96O09GUIOGagsHXhjTD1but4AYc6lBvjYXNzvZmQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1648511481; a=rsa-sha256; cv=none; b=gZ9QUtoh2lRXcVPhYYvuNkLMCCPsxJ+0BcqpKvU0P0P0M5rU984coVGg57ASghJLFBWHJR L9JK0K6eBix2Z8KR5HQturRFgqe3vwiftJwBlH0D/YaovzicsNZLHFfO597VMm5HOi4Nay z81L5WsLAbsIHt2eDQPOhEaF2fG9XDLEWX3hDZRXBrRgStywt+y6AjOF0M3IbNi72y/Vg3 H0rOgKEsvs1aeaKLgirvCbTKAN4e2TwMEXAPgntAgMNib/EWIXUcC+ZiLP7occhF+AmFNK gExv/gPVcdgKyFnRgJV+E3ig9Abpx6SLprz3WF/Gw4dQ6pUa5cH8EQwK8fudQw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=brendan.scot header.s=MBO0001 header.b=bzMKAgx3; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -9.37 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=brendan.scot header.s=MBO0001 header.b=bzMKAgx3; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 8BDA321E03 X-Spam-Score: -9.37 X-Migadu-Scanner: scn0.migadu.com X-TUID: O6bNOkwSjRsh This is a multi-part message in MIME format. --------------iFPw8I5kUdkOXOqZnomyLJ01 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 25/3/22 18:05, Paul Alesius wrote: > Rust analyzer is a language server for the Rust programming language. > > I've tried to produce a patch for the latest version, and it has > probably hundreds of dependencies that need to be updated. [...] > I'd suggest that a Guix package for rust-analyzer is not needed, > especially due to the excessive time required to update its package > definition and all of the vendored dependency crates, and focus should > instead be on rust and rust-cargo. I understand how defeating it feels when looking at the countless hundreds of dependencies that get pulled in, however, I believe this can be solved by improving the importers in Guix.  I think it requires too much manual labour to maintain packages curretly, particularly when refresh -u will only update the package version and not dependencies. Therefore I'm working on making use of https://github.com/rust-lang/crates.io-index to fully import base definitions all required crates rather than pulling metadata from the internet with each refresh. Maintaining rust packages then becomes mostly 1. Refresh generated package definitions 2. In a separate file edit any hacks/fix needed argument fields etc 3. Edit cargo-build-system to account for the most common hacks like setting LIBCLANG_PATH. It should be easy for a guix user to get all the latest crates that they would get using cargo. I think importers can be taken to the next level by going beyond metadata and actually inspecting the contents of source files. For example grepping build files it can be determined if pkg-config is used and add it to inputs. an index of .pc files can automatically detect and add the inputs a package is most likely looking for. One complaint about Guix is that typically just running ./configure; make on a project will not work, but if a guix can have a Universal Importer where running guix wave-magic-wand in a directory can inspect files, determine the build system, required inputs etc and build a program, would that not be wonderful for programmers? Working on KDE made me feel like I was wasting too much time manually adding inputs and would be better of writing an importer. Using rust in a hypothetical, imagine if a rust developer that is otherwise uninterested in Guix, they just want to build their software and distribute actually chooses to use Guix not due to idealism but because it: A. Handles their rust dependecies at least as well as cargo. B. Handles their non-rust dependencies even better. C. Improved Guix pack/build can produce distributable packages, stripped of uneeded files that actually runs on other distributions. Would that not be awesome? --------------iFPw8I5kUdkOXOqZnomyLJ01 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 

    

      
On 25/3/22 18:05, Paul Alesius wrote:

    

    

      
Rust analyzer is a language server for the Rust programming language.

I've tried to produce a patch for the latest version, and it has
probably hundreds of dependencies that need to be updated.


    

    
[...]


    

      
I'd suggest that a Guix package for rust-analyzer is not needed,
especially due to the excessive time required to update its package
definition and all of the vendored dependency crates, and focus should
instead be on rust and rust-cargo.


    

    
I understand how defeating it feels when looking at the countless hundreds of
dependencies that get pulled in, however, I believe this can be solved by
improving the importers in Guix.  I think it requires too much manual labour to
maintain packages curretly, particularly when refresh -u will only update the
package version and not dependencies.

    
Therefore I'm working on making use of
https://github.com/rust-lang/crates.io-index to fully import base definitions
all required crates rather than pulling metadata from the internet with each refresh.

    
Maintaining rust packages then becomes mostly
1. Refresh generated package definitions
2. In a separate file edit any hacks/fix needed argument fields etc
3. Edit cargo-build-system to account for the most common hacks like setting
LIBCLANG_PATH.

It should be easy for a guix user to get all the latest crates that they would
get using cargo.

    
I think importers can be taken to the next level by going beyond metadata and
actually inspecting the contents of source files. For example grepping build
files it can be determined if pkg-config is used and add it to inputs. an index
of .pc files can automatically detect and add the inputs a package is most
likely looking for. One complaint about Guix is that typically just running
./configure; make on a project will not work, but if a guix can have a Universal
Importer where running guix wave-magic-wand in a directory can inspect files,
determine the build system, required inputs etc and build a program, would that
not be wonderful for programmers? Working on KDE made me feel like I was wasting
too much time manually adding inputs and would be better of writing an importer.

Using rust in a hypothetical, imagine if a rust developer that is otherwise
uninterested in Guix, they just want to build their software and distribute
actually chooses to use Guix not due to idealism but because it:
A. Handles their rust dependecies at least as well as cargo.
B. Handles their non-rust dependencies even better.
C. Improved Guix pack/build can produce distributable packages, stripped of
uneeded files that actually runs on other distributions.

Would that not be awesome?



  


--------------iFPw8I5kUdkOXOqZnomyLJ01--