On Thu, Sep 08, 2016 at 21:54:36 +0200, Jan Nieuwenhuizen wrote:
> The question I'm trying to answer is: how does `a user' who builds a
> package from the repository install the needed dependencies.

Sorry, I misinterpreted.

`npm install <pkg>' will by default install all devDependencies; the
`--production' flag suppresses that behavior.

Many packages define a command to be run when `npm test` is invoked,
which would in turn need the devDependencies to run the test suite.

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

No, they don't.  I'm not sure if it's even possible with how npm works,
though I haven't done that sort of research.

But that'd be Guix' responsibility---just because npm doesn't offer a
way to do that doesn't mean that Guix can't, provided that there is an
automated way to track down each of the packages and determine how they
are built.  Some might use Make, some Grunt, nothing, etc.

> 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.

I'm hoping such code is precisely what this project produces. :)

> 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).

As I mentioned, I don't see a difference between this situation and
packaging other software that has no distinction between source code and
"binary" distribution.  It's just a hell of a lot more complex and the
package manager used to manage these packages (npm) doesn't care about
these issues.

Corresponding source code must include everything needed to build the
software, and must be the preferred form of modifying that
software.  This assumption cannot be made with the state of the packages
in the npm repository.  Some of the files might not even be in the
source repository (e.g. generated).

I have great faith in Guix and its mission; it would be a shame to see
that tainted by something like this.  Normally someone will look over a
package manually before adding it; but mass-adding thousands of packages
in an automated manner is even _more_ of an argument for the importance
not trusting binary distributions.


With all that said, I have no idea how it'll be done.  Someone could
just add any old file to the published npm package and never commit it
to any source repository.  I've done that accidentally.  I don't know
how you'd handle situations like that.  I don't know how you'd handle a
situation where a build script doesn't even work on a machine other than
the author's.  I don't know how you confirm that the software produced
from a build will actually be the same as the software normally
installed when you invoke `npm install <pkg>`.

If a package doesn't build from source, contain all the necessary files,
etc, it's not practical to exercise your freedoms, and so including it
would be bad.  But if one dependency out of thousands has that problem,
then what?  If one of the dependencies happens to actually contain
non-free code, then what?

When I evaluate software offered to GNU, I have to consider each and
every dependency.  This usually isn't a difficult task---many libraries
are standard, have already been reviewed by a project like Debian, and
there's rarely more than a few dozen of them.  I then build it from
source.  If I have the packages on my system (Trisquel at present), I
know that they're free and can be built from source.  Otherwise, I must
compile the library myself, recursively as needed for all
dependencies (which is usually not an issue).  If any of those were a
problem at any point, then the whole of the project is a problem.  If
any of those dependencies are non-free, the whole of the project is
non-free unless it can be swapped out.  If one obscure library requires
several dark incantations and a few dead chickens, users can't
practically exercise their freedoms, and that would be a problem for the
package.

Now how the hell is this enforced with thousands of dependencies that
have not undergone any review, within a community that really couldn't
care less?  Even something as simple as the license: package.json has no
legal force; it's _metadata_.

I feel like this will have to be manually checked no matter how it is
done; any automated process would just be a tool to aid in a
transition and keeping a package up-to-date.  I don't really see any
other way.

So I think that I share in your concern with how such a thing would
possible be done.  My point is that if it can't, it shouldn't be at all
(where is where we differ).

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: 2217 5B02 E626 BC98 D7C0  C2E5 F22B B815 8EE3 0EAB
https://mikegerwitz.com