The the Node.js guidelines say about Source0 [1]:
"The canonical method for shipping most node modules is tarballs from the npm registry"
and
"This method [PP: tarbals from npm] should be preferred to using checkouts from git or automatically generated tarballs from GitHub."
But I think that in following cases it would be better to use sources from the upstream project:
1) When the license is not included in NPM but is in upstream project. o Because we are not supposed to ship the license separate from the sources. 2) When the tests are not included. o In this case we need to download the sources from NPM and from upstream project, which seems redundant and a waste of work. 3) When NPM content is generated and source files are not in NPM. o This would mean to download sources from NPM and upstream project, delete the NPM sources in prep and generate the files again.
Are there good reason to enforce the use of NPM sources which I am missing? What is your opinion?
I would like to suggest to ad those three exceptions to the guidelines.
Piotr
[1]: https://fedoraproject.org/wiki/Packaging:Node.js?rd=Node.js/Packagers#Using_...
On 23/10/15 20:13, Piotr Popieluch wrote:
But I think that in following cases it would be better to use sources from the upstream project:
- When the license is not included in NPM but is in upstream project. o Because we are not supposed to ship the license separate from the
sources. 2) When the tests are not included. o In this case we need to download the sources from NPM and from upstream project, which seems redundant and a waste of work. 3) When NPM content is generated and source files are not in NPM. o This would mean to download sources from NPM and upstream project, delete the NPM sources in prep and generate the files again.
Are there good reason to enforce the use of NPM sources which I am missing? What is your opinion?
I would like to suggest to ad those three exceptions to the guidelines.
I agree, and in practice it is what I have been doing for some time, and as I update older modules I tend to convert the ones that were originally fetching tests separately to just use github as the source.
Tom
On Fri, Oct 23, 2015 at 3:26 PM, Tom Hughes tom@compton.nu wrote:
I agree, and in practice it is what I have been doing for some time, and as I update older modules I tend to convert the ones that were originally fetching tests separately to just use github as the source.
For what it's worth, I've taken the "dl-tests.sh" script that Jamie originally used to download the tests and revamped it to automatically grab the version and github repo from the spec file, find the right git commit hash for that version, and grab the test, support, docs, and examples directories from GitHub. I'm happy to share that script with the list -- or just look at any of my recent SRPMs and you'll see it in there.
One advantage I see to continuing to use registry.npmjs.org as the location is that many of the NodeJS packages seem to switch github repos from time to time. Just in the last few days I've come across three or four packages where this has happened.
That being said, many of you are much more familiar with NodeJS (and NodeJS packaging) than I am -- so I'll defer to the group consensus on this.
On 28/10/15 13:12, Jared K. Smith wrote:
One advantage I see to continuing to use registry.npmjs.org http://registry.npmjs.org as the location is that many of the NodeJS packages seem to switch github repos from time to time. Just in the last few days I've come across three or four packages where this has happened.
I do use npmjs as the version tracking method in anitya so I would normally discover fairly quickly if something moved.
I mean I do use npmjs for the package source where I can but if it's not all there then I just switch to github instead.
Tom
On Wed, Oct 28, 2015 at 9:20 AM, Tom Hughes tom@compton.nu wrote:
I do use npmjs as the version tracking method in anitya so I would normally discover fairly quickly if something moved.
Fair enough. I'll not worry too much about packages that use the github-generated tarballs as the source instead of NPM then when I'm doing package reviews.
-- Jared Smith
"Jared K. Smith" jsmith@fedoraproject.org wrote a very long time ago:
I agree, and in practice it is what I have been doing for some time, and as I update older modules I tend to convert the ones that were originally fetching tests separately to just use github as the source.
For what it's worth, I've taken the "dl-tests.sh" script that Jamie originally used to download the tests and revamped it to automatically grab the version and github repo from the spec file, find the right git commit hash for that version, and grab the test, support, docs, and examples directories from GitHub. I'm happy to share that script with the list -- or just look at any of my recent SRPMs and you'll see it in there.
One advantage I see to continuing to use registry.npmjs.org as the location is that many of the NodeJS packages seem to switch github repos from time to time. Just in the last few days I've come across three or four packages where this has happened.
That being said, many of you are much more familiar with NodeJS (and NodeJS packaging) than I am -- so I'll defer to the group consensus on this.
Without being any more familiar with NodeJS: I dislike the dl-tests.sh route because it adds another layer of indirec- tion (in addition to being not documented :-)). AFAICT, a patch à la:
| diff --git a/nodejs-yargs-parser.spec b/nodejs-yargs-parser.spec | index dec5f8a..9d006c6 100644 | --- a/nodejs-yargs-parser.spec | +++ b/nodejs-yargs-parser.spec | @@ -11,11 +11,7 @@ Summary: The mighty option parser used by yargs | License: ISC | URL: https://github.com/yargs/yargs-parser | Source0: https://registry.npmjs.org/%%7Bpackagename%7D/-/%%7Bpackagename%7D-%%7Bversi... | -# The test files are not included in the npm tarball. | -# Source1 is generated by running Source10, which pulls from the upstream | -# version control repository. | -Source1: tests-%{version}.tar.bz2 | -Source10: dl-tests.sh | +Source1: %{url}/archive/v%{version}.tar.gz | | | ExclusiveArch: %{nodejs_arches} noarch | @@ -35,7 +31,7 @@ The mighty option parser used by yargs | %prep | %autosetup -n package | # setup the tests | -%autosetup -T -D -a 1 -n package | +tar --strip-components=1 -xf %{SOURCE1} %{packagename}-%{version}/test | | %build | # nothing to do!
makes it clearer to casual packagers where the source comes from (and where it ends up) while retaining npmjs.org as the primary source. This would duplicate the source code out- side of test/ as it is contained once in yargs-parser-7.0.0.tar.gz and once in v7.0.0.tar.gz, but I think the simplification would be worth the extra space needed.
Tim
nodejs@lists.fedoraproject.org
-
Jared K. Smith -
Piotr Popieluch -
Tim Landscheidt -
Tom Hughes