Re: Merging the “binary” NPM importer?

[Timothy Sample]

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.


-- Tim