unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Brendan Tildesley <mail@brendan.scot>
To: guix-devel@gnu.org, Maxime Devos <maximedevos@telenet.be>,
	John Soo <jsoo1@asu.edu>
Subject: Improving importers best investment for growing gnu/packages/
Date: Tue, 29 Mar 2022 10:50:27 +1100	[thread overview]
Message-ID: <e9c52497-3fae-5e22-928b-0ecc6018fbee@brendan.scot> (raw)
In-Reply-To: <CAL8jUGWWt4HpOXpaLfZG-HSUxBXVgULBX8guAjkRAZ=TwZay7A@mail.gmail.com>

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

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?

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

  parent reply	other threads:[~2022-03-28 23:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-25  8:05 Packaging rust-analyzer is not necessary Paul Alesius
2022-03-26 15:30 ` Maxime Devos
2022-03-26 16:33   ` John Soo
2022-05-09 19:06     ` Maxime Devos
2022-03-28 23:50 ` Brendan Tildesley [this message]
2022-03-29  9:01   ` Improving importers best investment for growing gnu/packages/ Maxime Devos
2022-03-29 10:30     ` Brendan Tildesley
2022-03-29 19:03   ` Liliana Marie Prikler
2022-05-02  9:19   ` zimoun

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

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to=e9c52497-3fae-5e22-928b-0ecc6018fbee@brendan.scot \
    --to=mail@brendan.scot \
    --cc=guix-devel@gnu.org \
    --cc=jsoo1@asu.edu \
    --cc=maximedevos@telenet.be \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).