Hello Timothy, Timothy Sample <samp...@ngyro.com> writes:
> Hi Maxim, > > Maxim Cournoyer <maxim.courno...@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
