[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NPM and trusted binaries

From: Jan Nieuwenhuizen
Subject: Re: NPM and trusted binaries
Date: Thu, 08 Sep 2016 21:54:36 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Mike Gerwitz writes:

> On Thu, Sep 08, 2016 at 10:45:57 +0200, Jan Nieuwenhuizen wrote:
>> If a user builds an npm package from its source repository, I assume
>> that they install the devDependencies needed for that using npm?
> Unfortunately that depends on the project.  Some projects use
> devDependencies only for things like linters, test runners, assertion
> systems, etc; others might need them for building.

The question I'm trying to answer is: how does `a user' who builds a
package from the repository install the needed dependencies.

I very much doubt that users install the essential dependencies all by
building those from the source repository.  How would they do that?

My working hypothesis is that it's impossible to do so for any
moderately interesting npm package.  And I would very much like someone
to show me (with working code) that instead it is possible.

>> The transitive closure of installing all devDependencies for the `q'
>> package by building them all from their source repositories, means
>> building > 6000 packages.
> Many of those packages are shared between others.

Not so.  The total sum of interrelated dependencies to build `q' is over
41,000.  The number of imported packages for `q' using Jelle's importer
with some small fixes by me is over 6,000 unique dependencies and over
500 that can currently not be resolved by the importer and error out.

Please show me that building `q' this way is possible and what the
benefits are (in terms of software freedom) of spending our energy by
upholding the source/binary metaphor (even if for a majority of packages
there may not be a difference).


Jan Nieuwenhuizen <address@hidden> | GNU LilyPond
Freelance IT | Avatar®  

reply via email to

[Prev in Thread] Current Thread [Next in Thread]