[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
- Re: Merging the “binary” NPM importer?, Maxim Cournoyer, 2021/10/07
- Re: Merging the “binary” NPM importer?, Katherine Cox-Buday, 2021/10/08
- Re: Merging the “binary” NPM importer?,
zimoun <=
- Re: Merging the “binary” NPM importer?, Timothy Sample, 2021/10/12
- Re: Merging the “binary” NPM importer?, Maxim Cournoyer, 2021/10/13
- Re: Merging the “binary” NPM importer?, Ludovic Courtès, 2021/10/14
- Opining on "modern" development practices (was Re: Merging the “binary” NPM importer?), Katherine Cox-Buday, 2021/10/14
- Re: Opining on "modern" development practices (was Re: Merging the “binary” NPM importer?), Ludovic Courtès, 2021/10/21
- Re: Opining on "modern" development practices (was Re: Merging the “binary” NPM importer?), Katherine Cox-Buday, 2021/10/28
- Re: Opining on "modern" development practices (was Re: Merging the “binary” NPM importer?), Ludovic Courtès, 2021/10/29
- Re: Opining on "modern" development practices (was Re: Merging the “binary” NPM importer?), Katherine Cox-Buday, 2021/10/29