[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Merging the “binary” NPM importer?
From: |
Maxim Cournoyer |
Subject: |
Re: Merging the “binary” NPM importer? |
Date: |
Wed, 13 Oct 2021 21:26:12 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Hello Timothy,
Timothy Sample <samplet@ngyro.com> writes:
> Hi Maxim,
>
> 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.
>
> The reason I called it the “NPM Binary Importer” was to scare people
> away, because its results are rather limited. Maybe I went too far,
> though, and people are too scared! :)
>
> It’s more accurately the “Half-finished NPM Importer”. It produces
> packages that are missing two important parts: the dependencies needed
> to build the package; and the upstream source code location. Getting
> the dependencies is quite hard, since NPM doesn’t differentiate between
> build tools, testing frameworks, linters, scripts for publishing, etc.
> This results in a ton of circular dependencies since the publishing
> scripts use linters, and the linters use build tools, and the build
> tools use publishing scripts, etc., etc. We would need some sort of
> block list to get around this (e.g., we should just skip over stuff like
> ESLint). Getting the source code can be tricky, too. Normally, NPM
> packages have a “repository” field that points to the source code
> repository. However, in some cases, packages use a monorepo setup where
> many packages are produced from one repository. This complicates the
> correspondence between source code repositories and NPM packages.
>
> What the “binary” importer does is ignore all the “development”
> dependencies, use the NPM tarball as the package source, and set the
> ‘#:build?’ argument to false. This is a hack to get the half-finished
> importer to produce working (even if unpleasant) packages.
>
> I write all this to make it clear that the fact the importer produces
> “binary” packages is not the result of a “who cares about free software
> or source code?” attitude! :) It just seemed like a reasonable
> checkpoint between nothing and a Guix-ready NPM importer.
>
> I think keeping the half-finished importer alive by including it in Guix
> might be a good strategy. It might help us work – collectively –
> towards the goal of providing a clean, freedom respecting collection of
> JavaScript packages in Guix.
>
> Of course, I do respect and understand your concerns. After all, I
> called it the “binary” importer to be as scary as possible! In the end,
> it’s up to you and the other maintainers – hopefully my explanations are
> helpful.
Thanks for sharing all this background information! It helped a lot to
refine my current understanding of where this importer came from and
where it's heading; I must confess I hadn't reviewed the importer
details and the idea I had of it was mostly attributable to its scary
name :-).
In light of your message though, I think it may be fine to have the
importer in Guix as long as it is labeled as a technology preview, with
its current shortcomings documented :-). This may make it more
accessible and allow to refine it faster.
Thanks again,
Maxim
- 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?, Timothy Sample, 2021/10/12
- Re: Merging the “binary” NPM importer?,
Maxim Cournoyer <=
- 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