[opensuse-packaging] Re: Any plan to submit npm to Factory?
Hi Marguerite, On Sat, 20 Sep 2014 20:42:11 +0800 "marguerite" <i@marguerite.su> wrote:
Hi, Joachim,
Can we submit npm w/ all its dependencies and related tools like gyp to Factory before Beta?
Yes, of course. I actually wanted to do that on Friday but had to leave the office on short notice.
npm is now a separate package, thus the nodejs in Factory is now not able to build anything nodejs. But there're packages in Factory seem to rely on npm to build.
I split it off because I figured just for running the prepackaged node.js packages, npm is not required so why force installing it.
So we now face a mut-be-done choice:
1. fix the packages in Factory by the "manual copy" method to avoid using of npm 2. drop the packages (and even nodejs itself) from Factory, guide our users to use d:l:nodejs to develop their nodejs applications. 3. submit the splitted stuff to Factory, which will be ?50 packages, before Beta.
I think we'll want to have node.js support in Factory eventually, so we might as well go ahead and submit them.
BTW, I don't like the "manual copy" method, which is:
1. changeable over releases (if upstream add new files, your package will success anyway) 2. too much things needed to be judged by human-being (like which one to copy?) 3. it may needs a local test environment for the packager, which will force the packager to be a real nodejs developer. So it'll break our BURP way of packaging.
and actually this method can be done by robots like things done by our perl CPAN robots. It undervalues human-being, or even challenges human-being because we are much more easy to get things wrong than a robot.
I agree in theory that having a generic installation method is preferable to doing it manually, however the npm local install command has its downside too IMHO. npm install simply copies the whole package into the node_modules directory, including documentation, test files, potentially included packages the package depends on, even dotfiles like .gitignore. This means you have to manually clean up after npm anyway, which kinda defeats the point of using it.
But anyway this way is super fast, we can package 50 packages for one night. Anyway if we want to keep both ways of packaging ("manual copy" && "patch package.json") available, we still need to make a decision whether or not to submit those development tools to Factory.
Given that npm was in Factory before we actually removed functionality, so I think it should go back in asap. I'll submit it. Btw, thanks for fixing all the spec files. Cheers Joe -- ISV Technical Manager SUSE LINUX Products GmbH -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, Joachim,
Yes, of course. I actually wanted to do that on Friday but had to leave the office on short notice.
I'm working on it. and sent some of the packages Factory... there're still 50% packages unsent.
I agree in theory that having a generic installation method is preferable to doing it manually, however the npm local install command has its downside too IMHO. npm install simply copies the whole package into the node_modules directory, including documentation, test files, potentially included packages the package depends on, even dotfiles like .gitignore. This means you have to manually clean up after npm anyway, which kinda defeats the point of using it.
Unlikely I found that...so forgot what I've said. Once concern is: Dependencies to bootstrap NPM are about 100 nodejs packages. And it's growing. e.g. nodejs-request has new version, which introduces 10 dependencies, which further introduces another 10 dependencies... So do an update for npm is really painful now... Another concern is: Maybe the update doesn't mean to update everything to the latest verisons. e.g. If npm wants some specific versions...that'll be painful again... By now we didn't take the version requirements in package.json into consideration, So if someday bugs happened because of that, it might be impossible to debug so many Javascripts... Marguerite
Hi Marguerite, On Mon, 22 Sep 2014 22:58:40 +0800 "marguerite" <i@marguerite.su> wrote:
Yes, of course. I actually wanted to do that on Friday but had to leave the office on short notice.
I'm working on it. and sent some of the packages Factory... there're still 50% packages unsent.
Ok, cool.
I agree in theory that having a generic installation method is preferable to doing it manually, however the npm local install command has its downside too IMHO. npm install simply copies the whole package into the node_modules directory, including documentation, test files, potentially included packages the package depends on, even dotfiles like .gitignore. This means you have to manually clean up after npm anyway, which kinda defeats the point of using it.
Unlikely I found that...so forgot what I've said.
Once concern is:
Dependencies to bootstrap NPM are about 100 nodejs packages.
And it's growing. e.g. nodejs-request has new version, which introduces 10 dependencies, which further introduces another 10 dependencies...
So do an update for npm is really painful now...
Another concern is:
Maybe the update doesn't mean to update everything to the latest verisons. e.g. If npm wants some specific versions...that'll be painful again...
By now we didn't take the version requirements in package.json into consideration, So if someday bugs happened because of that, it might be impossible to debug so many Javascripts...
Both true. I find packaging node.js modules generally quite tedious. They are often very small, sometimes just one js file with one function in it, but it's the way it is. I don't really have a good idea to do it differently. However, to deal with the large number of packages I had to submit, I wrote a script to fetch module information from registry.npmjs.org, download the tarball, and generate the spec file. It's a bit basic at the moment (e.g. it doesn't take version numbers of dependencies into account), but I guess it could be extended to handle that and also to handle updates rather than new packages only. Due npm registry and the (mostly) uniformity of node modules, those tasks are fairly well scriptable which could take some of the pain away. I'll look into it. Regards Joe -- ISV Technical Manager SUSE LINUX Products GmbH -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tue, Sep 23, 2014 at 4:17 AM, Joachim Gleissner <jgleissner@suse.com> wrote:
Hi Marguerite,
On Mon, 22 Sep 2014 22:58:40 +0800 "marguerite" <i@marguerite.su> wrote:
Yes, of course. I actually wanted to do that on Friday but had to leave the office on short notice.
I'm working on it. and sent some of the packages Factory... there're still 50% packages unsent.
Ok, cool.
I agree in theory that having a generic installation method is preferable to doing it manually, however the npm local install command has its downside too IMHO. npm install simply copies the whole package into the node_modules directory, including documentation, test files, potentially included packages the package depends on, even dotfiles like .gitignore. This means you have to manually clean up after npm anyway, which kinda defeats the point of using it.
Unlikely I found that...so forgot what I've said.
Once concern is:
Dependencies to bootstrap NPM are about 100 nodejs packages.
And it's growing. e.g. nodejs-request has new version, which introduces 10 dependencies, which further introduces another 10 dependencies...
So do an update for npm is really painful now...
Another concern is:
Maybe the update doesn't mean to update everything to the latest verisons. e.g. If npm wants some specific versions...that'll be painful again...
By now we didn't take the version requirements in package.json into consideration, So if someday bugs happened because of that, it might be impossible to debug so many Javascripts...
Both true. I find packaging node.js modules generally quite tedious. They are often very small, sometimes just one js file with one function in it, but it's the way it is. I don't really have a good idea to do it differently.
However, to deal with the large number of packages I had to submit, I wrote a script to fetch module information from registry.npmjs.org, download the tarball, and generate the spec file. It's a bit basic at the moment (e.g. it doesn't take version numbers of dependencies into account), but I guess it could be extended to handle that and also to handle updates rather than new packages only. Due npm registry and the (mostly) uniformity of node modules, those tasks are fairly well scriptable which could take some of the pain away. I'll look into it.
Is this script you mention available? I've been holding off on packaging a few nodejs packages, puppet-explorer specifically, due to not wanting to get into the dependency nodejs hell that npm was about to unleash. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, On Tue, 23 Sep 2014 12:15:22 -0400 Darin Perusich <darin@darins.net> wrote: [...]
However, to deal with the large number of packages I had to submit, I wrote a script to fetch module information from registry.npmjs.org, download the tarball, and generate the spec file. It's a bit basic at the moment (e.g. it doesn't take version numbers of dependencies into account), but I guess it could be extended to handle that and also to handle updates rather than new packages only. Due npm registry and the (mostly) uniformity of node modules, those tasks are fairly well scriptable which could take some of the pain away. I'll look into it.
Is this script you mention available? I've been holding off on packaging a few nodejs packages, puppet-explorer specifically, due to not wanting to get into the dependency nodejs hell that npm was about to unleash.
I haven't looked into writing a more general-purpose node.js packaging script yet. So far I only have that script to create new node packages. If that's of any use for you, I can send it to you. Regards Joe -- ISV Technical Manager SUSE LINUX Products GmbH -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Sep 25, 2014 at 9:57 AM, Joachim Gleissner <jgleissner@suse.com> wrote:
Hi,
On Tue, 23 Sep 2014 12:15:22 -0400 Darin Perusich <darin@darins.net> wrote:
[...]
However, to deal with the large number of packages I had to submit, I wrote a script to fetch module information from registry.npmjs.org, download the tarball, and generate the spec file. It's a bit basic at the moment (e.g. it doesn't take version numbers of dependencies into account), but I guess it could be extended to handle that and also to handle updates rather than new packages only. Due npm registry and the (mostly) uniformity of node modules, those tasks are fairly well scriptable which could take some of the pain away. I'll look into it.
Is this script you mention available? I've been holding off on packaging a few nodejs packages, puppet-explorer specifically, due to not wanting to get into the dependency nodejs hell that npm was about to unleash.
I haven't looked into writing a more general-purpose node.js packaging script yet. So far I only have that script to create new node packages. If that's of any use for you, I can send it to you.
That would be useful, please send it ;-) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (3)
-
Darin Perusich -
Joachim Gleissner -
marguerite