[Pkg-javascript-devel] npm debian package

[Jérémy Lal]

Thank you for your answer.

Here's a solution i can propose to npm debian maintainers (cc-ing them), so npm can
be installed without any patch nor restrictions, and still follow debian policy :

* npm-g install path is wrong just because process.installPrefix is "/usr/bin/node/../.."
  Solution : patch node instead so that installPrefix = /usr/local

* /etc/npmrc must be the place for system config.
  With /usr/local prefix, npm will search for /usr/local/etc/npmrc.
  Solution : at package postinst time, symlink it to /etc/npmrc. (same for npmignore).

What do you think of that ?

Also you did not explicitely answer my question about
"node_modules that would better be inside the tarball instead of packaged apart" :
none, all, or no opinion ?
Mind that it's up to debian package maintainers to take care of the compatibility
between versioned dependencies and make sure it all works.

Kind regards,
Jérémy.



PS:
npm release tarball is available there :
http://registry.npmjs.org/npm/-/npm-1.0.93.tgz
and watch url could be
http://registry.npmjs.org/npm/
(i couldn't find a friendlier one)



On 05/10/2011 18:25, Isaac Schlueter wrote:
> Yes, I'm ok with making this public.
> 
> The npm tarball from github is not the one to use.  You should use the
> tarball from the npm registry, which does have the dependencies
> bundled, and docs built.  Everything in there *should* be MIT-licensed
> (if I wrote it, it definitely is)
> 
> If you disable any features, or use nonstandard mechanisms to
> configure npm's behavior, I would prefer if you did the following:
> 
> 1. Add a tag to the version in package.json.  So, for example, instead
> of "version":"1.0.93", it'd be something like
> "version":"1.0.93-jeremy-lal-debian" or something.  That way, error
> logs and such that come my way will be clearly distinguishable.
> 2. If the changes are significant enough that a user might report them
> as a bug (for instance, outright disabling global usage, which will
> make `npm link` and several other commands cease to function), then
> please set up a separate URL and email address for bug reporting, and
> change the references to the npm issues page and group email.
> 
> 
> Rather than make those changes, however, I would recommend approaching
> npm thusly:
> 
> 1. Do not patch npm's source code.  (If there are patches that would
> make it more extensible or flexible to your use-case, then I'd love to
> hear it, and I'm very open to contributions.)
> 2. Install npm in some prefix where debian laws allow it to do
> whatever the hell it wants.  Maybe something like
> "/usr/local/share/npm".  Then do the following to configure npm how
> you describe:
> 
> a. in $HOME/.npmrc:
> 
> prefix = /usr/local/share/npm
> globalconfig = /etc/npmrc
> globalignorefile = /etc/npmignore
> 
> Then, the install step is merely `make install && ln -s
> /usr/local/bin/npm /usr/local/share/npm/bin/npm`
> 
> 
> b. Print the following caveat on installation:
> 
> ```
> npm is installed in /usr/local/share/npm.
> 
> 
> To install npm programs that include executables, please add
> 
>     /usr/local/share/npm/bin
> 
> to your PATH environment variable.
> 
> 
> To view man pages from packages installed by npm, please add
> 
>     /usr/local/share/npm/share/man
> 
> to your MANPATH.
> ```
> 
> 
> c. On uninstallation, print this:
> 
> ```
> npm itself has been removed, but any programs installed with it
> are still in /usr/local/share/npm.
> 
> To remove them entirely, delete that directory.
> ```
> 
> 
> If you do this, then you get the following benefits:
> 
> 1. `npm install npm -g` or `curl http://npmjs.org/install.sh | sh`
> will work to upgrade, and will continue to obey the policy.
> 2. global installs will work (with the PATH caveat)
> 3. link installs will work.
> 
> 
> On Wed, Oct 5, 2011 at 06:40, Jérémy Lal <jerry at edagames.com> wrote:
>> Hi,
>> i'm currently working to get latest npm into debian.
>>
>> These are the only patches i had to make to follow debian policy :
>> * forbid npm -g update|install npm
>>  or else a user could end using an unpatched version that do not respect debian policy,
>> * use /etc/npmrc, /etc/npmignore, and prefix=/usr/local (instead of path.join(process.execPath, "..", ".."))
>>
>> As you can see the changes are minimal and won't confuse a debian user.
>> Tell me if you feel they are wrong in that usage context.
>>
>> Another matter is how to deal with the eleven dependencies that are not part of the tarball.
>> The debian way is to package each one of those independently, and then make npm package depend on them.
>> However, since you are the author of most of them, i wonder what do you think for each one of those :
>> node-semver
>> abbrev-js
>> nopt
>> minimatch
>> node-graceful-fs
>> slide-flow-control
>> rimraf
>> proto-list
>> ini
>> node-which
>> uuid (but you are not the author of that one)
>>
>> Should they be packaged independently, or would you rather keep them in npm tarball ?
>> I read what you think about not promoting "slide" for wide usage, so maybe it's an example
>> of a dependency that would better be inside the tarball instead of packaged apart.
>>
>> It'd be great to have your opinion.
>>
>> Regards,
>> Jérémy Lal
>>
>>
>> PS: please tell me if you're ok with making this dicussion public.
>>