From: Katherine Cox-Buday <cox.katherine.e@gmail.com>
To: pinoaffe <pinoaffe@airmail.cc>
Cc: guix-devel@gnu.org
Subject: Re: Merging the “binary” NPM importer?
Date: Mon, 27 Sep 2021 10:13:36 -0500 [thread overview]
Message-ID: <87o88eqcf3.fsf@gmail.com> (raw)
In-Reply-To: <87mtny1jmc.fsf@airmail.cc> (pinoaffe@airmail.cc's message of "Mon, 27 Sep 2021 10:57:15 +0200")
pinoaffe <pinoaffe@airmail.cc> writes:
> Hi,
>
> Philip McGrath writes:
>> This did seem to happen with a large package I imported, but the
>> multiple versions coexisting seemed to work ok.
> Oh okay, it didn't really seem to work in my tree - yet another argument
> for merging it, in order to unify it :)
+1, if this works. These packages aren't meant to end up in Guix anyway, so if there's a lot of duplicates, it only harms the local store, or a channel.
Maybe someday Guix can untangle the JS ecosystem knot, but in the meantime this unblocks folks.
>
>> Ultimately, Guix will somehow need to deal with the messy versioning
>> of the NPM world, and it would be nice to keep the duplication to a
>> minimum, but that seems like it might be a challenge.
> I think it would be great if at some point we could somehow encode
> version constraints for dependencies in guix packages, as even if one
> were to properly package a bunch of npm packages, figuring out whether
> one can safely upgrade one of them without breaking any of the
> dependents would be quite a hassle (or would need to involve running a
> lot of builds to see whether they fail).
This sounds neat. And maybe pre-defined rules, e.g. semantic versioning?
Good luck!
--
Katherine
next prev parent reply other threads:[~2021-09-27 15:14 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 [this message]
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
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o88eqcf3.fsf@gmail.com \
--to=cox.katherine.e@gmail.com \
--cc=guix-devel@gnu.org \
--cc=pinoaffe@airmail.cc \
/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 external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.