Re: Improving importers best investment for growing gnu/packages/

[Liliana Marie Prikler]

Am Dienstag, dem 29.03.2022 um 10:50 +1100 schrieb Brendan Tildesley:
> 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.
I'm not sure how this is for Rust packages, but in general, I'd
consider over-reliance on `guix refresh' more harmful than not.  There
has recently been a paper published, which shows this to be the case
for spreadsheet debugging – give people a smell checker without
appropriate hints where it might be flawed and they will be worse at
finding flaws than the control group.  I make a claim, that it's the
same for packaging software.  Our importers should come with a warning
sign attached that they perform the best possible approximation based
on available metadata, but that they might be missing important
information or contain bugs, and that the output needs human
verification.

In general, even though one might claim that this conclusion has been
largely forgone in the case of cargo, npm, et al., human intelligence
is a requirement in human computer interaction.  Trying to take too
much of it away leads to adverse effects rather than "smart systems".

> 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.
That'd probably fine for pkg-config as a single package, but to get
packages to a working state, you'll have to do so for more than just
pkg-config (you list dependencies referenced by pkg-config below, for
example).  Speaking more generally, short of actually running the build
(repeatedly) against all possible combinations of inputs, you will not
obtain a complete or accurate input set (particularly also considering
that some of said inputs might not even be packaged).  And even if you
do, all your machine could then tell you, is that it builds; not
whether it functions as intended.  This also assumes that the source
won't need to be patched to remove icky stuff, no phase needs to be
adjusted, ...

> 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.
To be fair, scanning pkg-config files sounds like a good idea until you
consider it is but a heuristic and pkg-config names do not easily map
to package names.

> 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 unneeded files that actually runs on other distributions.
> 
> Would that not be awesome?
Hypothetically speaking, apart from the fact that rust inputs are not
inputs because the Rust ecosystem is awful, maintaining a guix.scm on
the side of your Rust package should not be that much more difficult
than maintaining a cargo.toml.  And better yet, you don't need those
god-awful lock files, you could just commit a channels.scm as well if
bit-for-bit reproducibility in CI is a requirement.  You could even
implement a scheme-based toml parser, that establishes a 1:1 mapping
between toml and guix package.  Ironically, Javascript is ahead in that
regard, as someone has already written a Guix package reader in
ECMAScript.  Wisp is also an option for those experiencing terminal
parenthephobia.

IMHO the onus is on Rust to create an ecosystem that does not collapse
if someone removes leftpad.