unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: Katherine Cox-Buday <cox.katherine.e@gmail.com>
Cc: Guix Devel <guix-devel@gnu.org>,
	Maxim Cournoyer <maxim.cournoyer@gmail.com>
Subject: Re: Merging the “binary” NPM importer?
Date: Mon, 11 Oct 2021 12:13:04 +0200	[thread overview]
Message-ID: <CAJ3okZ1aFcU_1ak+N2XbLTHcJS4YYca2wu+wkZVA4aOV+CB=og@mail.gmail.com> (raw)
In-Reply-To: <87czoflhzx.fsf@gmail.com>

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	other threads:[~2021-10-11 10:13 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-19 13:01 Adding extra package importers pinoaffe
2021-09-19 14:44 ` Maxime Devos
2021-09-23 20:28 ` Merging the “binary” NPM importer? Ludovic Courtès
2021-09-23 23:13   ` pinoaffe
2021-09-26 13:37     ` Jelle Licht
2021-09-26 21:34       ` pinoaffe
2021-09-26 22:32         ` Philip McGrath
2021-09-27  8:57           ` pinoaffe
2021-09-27 15:13             ` Katherine Cox-Buday
2021-09-28 12:37       ` Ludovic Courtès
2021-09-25  3:17   ` Christine Lemmer-Webber
2021-10-08  1:51     ` Maxim Cournoyer
2021-10-08 14:16       ` Katherine Cox-Buday
2021-10-11 10:13         ` zimoun [this message]
2021-10-11 17:12           ` pinoaffe
2021-10-12 18:21       ` Timothy Sample
2021-10-14  1:26         ` Maxim Cournoyer
2021-10-14 13:58           ` Ludovic Courtès
2021-10-14 14:54             ` Opining on "modern" development practices (was Re: Merging the “binary” NPM importer?) Katherine Cox-Buday
2021-10-21 19:39               ` Ludovic Courtès
2021-10-28 15:01                 ` Katherine Cox-Buday
2021-10-29 12:33                   ` Ludovic Courtès
2021-10-29 14:54                     ` Katherine Cox-Buday

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='CAJ3okZ1aFcU_1ak+N2XbLTHcJS4YYca2wu+wkZVA4aOV+CB=og@mail.gmail.com' \
    --to=zimon.toutoune@gmail.com \
    --cc=cox.katherine.e@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=maxim.cournoyer@gmail.com \
    /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).