Re: Merging the “binary” NPM importer?

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

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