Source0 for nodejs modules

[Piotr Popieluch]

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

[Tom Hughes]

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

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

[Jared K. Smith]

On Fri, Oct 23, 2015 at 3:26 PM, Tom Hughes <tom(a)compton.nu&gt; 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.

[Tom Hughes]

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

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

[Jared K. Smith]

On Wed, Oct 28, 2015 at 9:20 AM, Tom Hughes <tom(a)compton.nu&gt; 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

[Tim Landscheidt]

"Jared K. Smith" <jsmith(a)fedoraproject.org&gt; 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/%{packagename}/-/%{packagename}-%{version}.tgz
| -# 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