guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Merging the “binary” NPM importer?


From: zimoun
Subject: Re: Merging the “binary” NPM importer?
Date: Mon, 11 Oct 2021 12:13:04 +0200

Hi,

On Fri, 8 Oct 2021 at 16:17, Katherine Cox-Buday
<cox.katherine.e@gmail.com> wrote:
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
> > I'm not too keen on having an importer which produces packages that
> > can't be included in Guix proper -- it seems a double standard to me.
> > I'd personally prefer to have such tool maintained outside of Guix
> > proper.
>
> I disagree with this because the benefit of Guix can extend beyond the 
> packages it provides. It is a computing environment and not the sum of its 
> parts.

Instead of a strong inclusion, one could imagine this importer as a
regular package using GUIX_EXTENSION_PATH.  For instance, it could be:

   guix install guix-import-npm

then something like:

  guix import-npm <options>

This just works, modulo some polishing and doc. :-)  For an example,
see the package gwl.  An example using another strategy is using a
channel, for instance
<https://framagit.org/tyreunom/guix-home-manager>.

I have not checked if this "extension" system could work for
subcommands as the importers, i.e., having something like:

   guix import npm

where this 'npm' would not be part of Guix proper (not in
guix/import/) but instead would be a package extending Guix.

This seems road to take, IMHO.

WDYT?


> I don't always have full control over my computing environments. There are 
> certain contexts, say my job, that require that I run binaries for which I 
> don't have source code. Guix having the flexibility to support me in these 
> contexts allows me to keep using, contributing, and supporting Guix. I.e., 
> there's a network effect.
>
> In my opinion, Guix should be the gentle current towards its free ecosystem. 
> But it should also acknowledge the wider world in which it exists, and be 
> supportive of its users in those contexts too. I don't think this in any way 
> diminishes the strong principles it adheres to.

I agree.  However, instead of include all directly in Guix proper, I
think it is better to make experiments outside Guix proper and in the
same keep the Guix tooling at hand.  And from my understanding, it
means extend Guix. :-)  If it shows it is worth, then let merge to
Guix.

Cheers,
simon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]