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 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. Given a sufficiently large pool of npm packages, there'll be a great deal of intersections in the graph. I haven't been following this closely enough to speak intelligently about the conversion, though. > I would also like to explore if the source/binary package metaphor is > a valid one for npm. Sure it is. > For the packages that I considered, I used the `diff' command to assert > that the installable npm package includes javascript and C files and are > identical to the ones in the repository. In some cases, this will be true. Possibly in a majority. Think of npm as publishing the results of `make dist` (literally, that's what I do). That could do anything, it could do pretty much nothing. If a Perl/Python/PHP/Ruby/Scheme/<insert interpreted language here> script is in the distribution tarball unmodified from the source, what considerations do we give it when packaging for, say, Debian? But we'd have to know that on a case-by-case basis. If we want a general solution to this problem, we wouldn't want to add a bunch of exceptions. If it's literally publishing the source code repository (which many are), then there is no distinction. But we'd have to know that to be true. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: 2217 5B02 E626 BC98 D7C0 C2E5 F22B B815 8EE3 0EAB https://mikegerwitz.com
signature.asc
Description: PGP signature