Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package [and 1 more messages]

[Bastien ROUCARIES]

On Mon, Mar 12, 2018 at 7:52 AM, Pirate Praveen
 wrote:
>
>
> On March 12, 2018 3:34:26 AM GMT+05:30, Bastien ROUCARIES 
>  wrote:
>>Done for node-has using node-function-bind but it break uscan for
>>node-has
>>
>>Bill could you get a glimpse, I will like to create something more
>>robust
>
> I think it is better to create a native Debian package (so no need for uscan 
> or repackaging) node-tiny-modules instead of adding to random modules.

Yes I concours but we could also improve uscan in order to get
something easier. It is orthogonal

Bastien

> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package [and 1 more messages]

[Pirate Praveen]

On March 12, 2018 3:34:26 AM GMT+05:30, Bastien ROUCARIES 
 wrote:
>Done for node-has using node-function-bind but it break uscan for
>node-has
>
>Bill could you get a glimpse, I will like to create something more
>robust

I think it is better to create a native Debian package (so no need for uscan or 
repackaging) node-tiny-modules instead of adding to random modules.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package [and 1 more messages]

[Bastien ROUCARIES]

On Sun, Mar 11, 2018 at 9:15 PM, Bill Allombert  wrote:
> On Sun, Mar 11, 2018 at 02:48:40PM +0530, Pirate Praveen wrote:
>> > * Some Javascript modules are very small, resulting in lots of small
>> >   packages
>>
>> I think we need to balance the small packages concern with number of
>> times such small packages are used.
>>
>> node-has was rejected recently because it was "too small". I agree if
>> only one, two or even three modules depend on it embedding it is okay (I
>> have been doing that already). But when more than three modules need a
>> tiny module? Is it really better to embed it that many times?
>
> You should not embed them. Instead you can merge several tiny
> modules together and ship them as a single .deb, which eventually
> Provides: node-mod1, node-mod2 etc. So package can still Depends on the
> individual names.

Done for node-has using node-function-bind but it break uscan for node-has

Bill could you get a glimpse, I will like to create something more robust

> Cheers,
> --
> Bill. 
>
> Imagine a large red swirl here.
>
> --
> Pkg-javascript-devel mailing list
> Pkg-javascript-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package [and 1 more messages]

[Bill Allombert]

On Sun, Mar 11, 2018 at 02:48:40PM +0530, Pirate Praveen wrote:
> > * Some Javascript modules are very small, resulting in lots of small
> >   packages
> 
> I think we need to balance the small packages concern with number of
> times such small packages are used.
> 
> node-has was rejected recently because it was "too small". I agree if
> only one, two or even three modules depend on it embedding it is okay (I
> have been doing that already). But when more than three modules need a
> tiny module? Is it really better to embed it that many times?

You should not embed them. Instead you can merge several tiny
modules together and ship them as a single .deb, which eventually
Provides: node-mod1, node-mod2 etc. So package can still Depends on the
individual names.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package [and 1 more messages]

[Pirate Praveen]

On ഞായര്‍ 11 മാർച്ച് 2018 04:59 വൈകു, Simon McVittie wrote:
> The reason I suggested that restriction was to avoid having contradictory
> requirements: if node-foo is the naming convention for the module
> that lets nodejs users require('foo'), and node-foo is also the naming
> convention for a nodejs executable that upstream refer to as foo where
> foo is too generic for Debian, then we might get a collision between
> the requirements for libraries and the requirements for executables.
> 
> But perhaps I'm being overly paranoid there, because the main extra
> requirement for executables with nodejs as an interpreter is "must depend
> on nodejs", and for a package named node-* that's hardly a burden.

In case of conflict, we can add js suffix to the executable. node ->
nodejs, babel -> babeljs.

The binary can be foo (since it has foo command) and it can provide
node-foo (since require 'foo' works).




signature.asc
Description: OpenPGP digital signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package [and 1 more messages]

[Simon McVittie]

On Sun, 11 Mar 2018 at 14:48:40 +0530, Pirate Praveen wrote:
> On വെള്ളി 09 മാർച്ച് 2018 08:39 വൈകു, Simon McVittie wrote:
> > And for executables, perhaps something like this:
...
> > * should not be named node-* without a suffix like -bin or -tools (?)
> 
> I don't think there is any particular benefit in this restriction.
> Having a uniform was to map node module name -> package name without
> having extra effort to check if it is an executable or library is
> helpful in automation (especially because we are talking about a large
> number of modules here). Manually finding if a module is already
> packaged vs automatically finding.

The reason I suggested that restriction was to avoid having contradictory
requirements: if node-foo is the naming convention for the module
that lets nodejs users require('foo'), and node-foo is also the naming
convention for a nodejs executable that upstream refer to as foo where
foo is too generic for Debian, then we might get a collision between
the requirements for libraries and the requirements for executables.

But perhaps I'm being overly paranoid there, because the main extra
requirement for executables with nodejs as an interpreter is "must depend
on nodejs", and for a package named node-* that's hardly a burden.

smcv

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package [and 1 more messages]

[Pirate Praveen]

On വെള്ളി 09 മാർച്ച് 2018 08:39 വൈകു, Simon McVittie wrote:
> I think saying "script" is perhaps unhelpful here, because outside
> Javascript, that usually refers to something executable with #! at the
> beginning.
> 
> It might be clearer to think about this in terms of libraries and
> executables: some Javascript packages are libraries (reusable code
> intended to be depended on by something else), some Javascript packages
> are executables (an executable script in /usr/bin or similar, starting
> with #!/usr/bin/nodejs or similar), and some have both.

I have followed the convention used in that document. I agree, changing
it to libraries and executables is better.

> As far as I know, Javascript has two interesting issues from a packaging
> point of view, which make it require some extra thought compared with
> Perl or Python:
> 
> * Some Javascript modules are very small, resulting in lots of small
>   packages

I think we need to balance the small packages concern with number of
times such small packages are used.

node-has was rejected recently because it was "too small". I agree if
only one, two or even three modules depend on it embedding it is okay (I
have been doing that already). But when more than three modules need a
tiny module? Is it really better to embed it that many times?

It is a question of number of packages vs number of duplicate copies and
duplicate manual work.

To summarize,

1. If more than three modules require a tiny module, it should be
packaged separately.

2. If only a single package is depending on a module, it could be
embedded to reduce the number of packages. But if a second package also
require it, then it should be packaged separately.

3. If a module involves some build/transformation steps, it should be
packaged separately t make managing it easier.

> * There are multiple Javascript runtimes/interpreters (nodejs, gjs,
>   seed, web browsers) and each Javascript library is usable by one or
>   more of those interpreters, but not necessarily by all of them
> 
> The second issue applies equally to Python: some Python libraries
> only work in CPython 2 (python-foo), some only work in CPython 3
> (python3-foo), and some also work in PyPy (pypy-foo). For Python, we've
> chosen to distribute libraries for those three runtimes as separate
> binary packages, because that doesn't result in an overwhelmingly large
> number of binary packages.
> 
> For Javascript, because some libraries (particularly in the nodejs
> ecosystem) are very small and numerous, following the same convention as
> Python would result in a very large number of binary packages, and the ftp
> team are uncomfortable about accepting those; so we might want to have
> a different policy, where (whenever possible) a single binary package
> libjs-foo provides the 'foo' library for all the runtimes it supports.

The main two runtimes, we currently target are browsers and nodejs. So
libjs-foo providing node-foo.

>> Exceptions (cases where a provides may be insufficient):
>> 1. should generate binary package 'foo' ('node-foo' in case of a name
>> conflict) and declare dependency on nodejs, if script includes a command
>> line tool
> 
> Perhaps a better way to think about this would be something like:
> 
> """
> If a Javascript source package includes reusable library code, then that
> part of the package should be packaged as a library:
> 
> * the binary package that enables you to require('foo') in nodejs should
>   either have Provides: node-foo or be named node-foo
> * if the library is designed for use by nodejs only, it should be in a
>   package named node-foo
> * if the library is usable by multiple Javascript interpreters, it should
>   be in a package named libjs-foo that Provides: node-foo
> """

Agreed.

Also we need to consider source package names as well. I think if a
project (library/tool) is distributed as a node module (it has a
package.json and available from npmjs.com) then the source package
should also be node-foo.

This is also helpful for 'npm2deb search' to determine if a module is
packaged already. Because of non standard names, sometimes we have to
duplicate efforts to get some modules packaged.

> (In case you haven't noticed, I'm a big fan of "names are APIs and
> APIs are names": I think the systematic policies that we have for some
> languages, where libfoo2 always means you can run binaries with
> DT_NEEDED: libfoo.so.2, libfoo-bar-perl always means you can "use
> Foo::Bar" in Perl, and python3-foo always means you can "import foo"
> in Python 3 are a very good idea.)

Agreed.

> And for executables, perhaps something like this:
> 
> """
> If a Javascript package includes an executable or executables that are
> useful in their own right, then they should be packaged in a binary package
> that represents those executables, as opposed to the library:
> 
> * must depend on the necessary interpreter, usually nodejs

Agreed.

> * must depend on any Javascript libraries that those 

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package

[Bastian Blank]

On Tue, Mar 06, 2018 at 02:12:52PM +, Ian Jackson wrote:
> Pirate Praveen writes ("Javascript team policy and rejection of node-three 
> binary package"):
> > 1. Node.js has standard locations for discovering installed packages
> > which is different from browser targeted javascript libraries.
> > Node.js expects pure js modules to be installed at /usr/lib/nodejs but
> > javascript libraries are installed at /usr/share/javascript
> This is not an argument in favour of separate packages AFAICT ?

No, it is not.

> > 2. Dependency on nodejs is required only during build or when other
> > Node.js modules depend on it. a browser targeted library does not need
> > to depend on nodejs package.
> This could be solved by dropping the nodejs dependency from all the
> nodejs module packages and requiring top-level applications to depend
> on nodejs.

And what problem would arise from this dependency?  What does it break,
so it _must_ not exist?

Bastian

-- 
Intuition, however illogical, is recognized as a command prerogative.
-- Kirk, "Obsession", stardate 3620.7

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package [and 1 more messages]

[Simon McVittie]

On Fri, 09 Mar 2018 at 17:50:30 +0530, Pirate Praveen wrote:
> How about the change given below? (is the intent clear at least even if
> disagreement on content remains)
> 
> 5. should add 'Provides: node-foo' in debian/control and install
> package.json in /usr/lib/nodejs/foo, if the script is usable also for
> Nodejs.

I think saying "script" is perhaps unhelpful here, because outside
Javascript, that usually refers to something executable with #! at the
beginning.

It might be clearer to think about this in terms of libraries and
executables: some Javascript packages are libraries (reusable code
intended to be depended on by something else), some Javascript packages
are executables (an executable script in /usr/bin or similar, starting
with #!/usr/bin/nodejs or similar), and some have both.

As far as I know, Javascript has two interesting issues from a packaging
point of view, which make it require some extra thought compared with
Perl or Python:

* Some Javascript modules are very small, resulting in lots of small
  packages

* There are multiple Javascript runtimes/interpreters (nodejs, gjs,
  seed, web browsers) and each Javascript library is usable by one or
  more of those interpreters, but not necessarily by all of them

The second issue applies equally to Python: some Python libraries
only work in CPython 2 (python-foo), some only work in CPython 3
(python3-foo), and some also work in PyPy (pypy-foo). For Python, we've
chosen to distribute libraries for those three runtimes as separate
binary packages, because that doesn't result in an overwhelmingly large
number of binary packages.

For Javascript, because some libraries (particularly in the nodejs
ecosystem) are very small and numerous, following the same convention as
Python would result in a very large number of binary packages, and the ftp
team are uncomfortable about accepting those; so we might want to have
a different policy, where (whenever possible) a single binary package
libjs-foo provides the 'foo' library for all the runtimes it supports.

> Exceptions (cases where a provides may be insufficient):
> 1. should generate binary package 'foo' ('node-foo' in case of a name
> conflict) and declare dependency on nodejs, if script includes a command
> line tool

Perhaps a better way to think about this would be something like:

"""
If a Javascript source package includes reusable library code, then that
part of the package should be packaged as a library:

* the binary package that enables you to require('foo') in nodejs should
  either have Provides: node-foo or be named node-foo
* if the library is designed for use by nodejs only, it should be in a
  package named node-foo
* if the library is usable by multiple Javascript interpreters, it should
  be in a package named libjs-foo that Provides: node-foo
"""

(In case you haven't noticed, I'm a big fan of "names are APIs and
APIs are names": I think the systematic policies that we have for some
languages, where libfoo2 always means you can run binaries with
DT_NEEDED: libfoo.so.2, libfoo-bar-perl always means you can "use
Foo::Bar" in Perl, and python3-foo always means you can "import foo"
in Python 3 are a very good idea.)

And for executables, perhaps something like this:

"""
If a Javascript package includes an executable or executables that are
useful in their own right, then they should be packaged in a binary package
that represents those executables, as opposed to the library:

* must depend on the necessary interpreter, usually nodejs
* must depend on any Javascript libraries that those executables need
* should not be named node-* without a suffix like -bin or -tools (?)
"""

I'm not sure how this would be phrased in a policy, but I think the
goal should perhaps be: if the user wants to run the uglifyjs(1)
command-line utility, they should be able to install a package that
represents the uglifyjs command-line tool, without needing to know
or care whether uglifyjs is itself written in Javascript, or whether
it's been reimplemented in Python or C or Perl. The goal of the user
of uglifyjs(1) is to minify/compress some Javascript, and the fact that
they do that by running a tool that is itself written in Javascript is
just an implementation detail.

This gets annoying if the name of the executable would be too generic
(namespace pollution) without a node- prefix, like node-static (I think
"static" would be a bad name for an executable), but perhaps that could be
packaged as node-static-tools or node-static-bin or something?

> 2. should generate binary package 'node-foo' in addition to 'libjs-foo',
> if the script requires a newer version of nodejs than available in
> testing. This is to facilitate proper testing migration (provides will
> not be sufficient to block migration to testing before required nodejs
> also migrates).

Breaks might be a better mechanism for this, but I'm not sure about the
corner cases. I think Breaks would prevent migration as long as there is
some other 

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package [and 1 more messages]

[Pirate Praveen]

On വെള്ളി 09 മാർച്ച് 2018 04:48 വൈകു, Ian Jackson wrote:
> But:
> 
>> 2. We won't be able to specify a minimum version of nodejs for these
>> modules.  For example, node-regexpu-core required nodejs >= 6 and
>> this prevented its testing migration for a long time because testing
>> only had nodejs 4 for a long time.
> 
> That is a problem, indeed.  Is this common ?
> Another possibility, though would be to use Breaks.  Eg
> 
>  Package: node-regexpu-core
>  Breaks: nodejs (<< 6~)

Would this stop the package from migrating to testing?
>>> If only a much smaller number of upstream packages have command line
>>> utilities, then we could have the number of JS .deb packages that need
>>> to be maintained by putting the node and browser files into the same
>>> package.
>>
>> I think the following change to point 5 of javascript policy [1] has
>> consensus now.
> 
> Woah, steady on there.  You only just posted this proposal.  It can't
> possibly have consensus yet!  Furthermore, I was mostly asking
> questions and exploring possibilities.

I was trying to summarize it based on my understanding of the responses
so far, it is anyway not final without confirmation from others. At
least the main part of reducing binary and replacing with provides seems
to be accepted without challenges. I agree the exception part was rushed
by me.

> I appreciate that you are keen to move forward, but to that end I
> would encourage you to engage quickly in this discussion, rather than
> waiting a while and then providing a bunch of answers combined with
> jumping straight to a policy change.

I was traveling so could not reply earlier, the wait was not intentional.

>> Change,
>>
>> 5. should generate a node-foo binary package if the script is usable
>> also for Nodejs
>>
>> to
>>
>> 5. should provide node-foo and install package.json in
>> /usr/lib/nodejs/foo if the script is usable also for Nodejs. If script
>> includes a command line tool, it should generate foo (node-foo in case
>> of a name conflict) binary package and declare dependency on nodejs. A
>> separate binary package should be generated if the script requires a
>> newer version of nodejs than available in testing to facilitate proper
>> testing migration.
> 
> This would seem to suggest *three* packages in some cases ?  I'm not
> sure I understand the intent.

May be I was not clear. It would be one binary plus provides or two
binaries in all cases. In case of a script needing newer nodejs features
not available in testing, adding provides to one binary will not be
sufficient to prevent it from migrating to testing.

How about the change given below? (is the intent clear at least even if
disagreement on content remains)

5. should add 'Provides: node-foo' in debian/control and install
package.json in /usr/lib/nodejs/foo, if the script is usable also for
Nodejs.

Exceptions (cases where a provides may be insufficient):
1. should generate binary package 'foo' ('node-foo' in case of a name
conflict) and declare dependency on nodejs, if script includes a command
line tool

2. should generate binary package 'node-foo' in addition to 'libjs-foo',
if the script requires a newer version of nodejs than available in
testing. This is to facilitate proper testing migration (provides will
not be sufficient to block migration to testing before required nodejs
also migrates).

> 
> Also your comments about namespace make me wonder: do many of these
> node scripts have poorly chosen command names ?  Can I get a list of
> them easily somehow ?

apt-file find /usr/bin |grep ^node-

will give most of it, but some packages like mocha only provides
node-mocha so the search should include source package names too.

> I don't think renaming the package only when there is a conflict is a
> good rule of thumb.  Instead, the package should be renamed when
> conflict is likely, even if it hasn't yet occurred.  The same goes for
> command names.

I don't think renaming just anticipating conflicts is good. Renaming has
a cost in extra documentation and causing confusion so it should be best
avoided.

> I think "handlebars" and "uglify" are OK for this, but I don't know
> what the whole ecosystem is like.  The controversy about the name
> "node" itself, and upstream's handling of that, don't give me
> confidence that the node.js upstream community have fully realised
> that the command namespace is a global resource, which they should be
> using with respect for others.
> 
> In practice, as an easier guideline, maybe it would be better to say
> that the command and package should *usually* be renamed, unless the
> script is high propfile and has a good name which is unlikely to
> conflict.

I don't agree. I don't think the benefit outweigh the cost. Changing
node to nodejs costed us so much effort in patching at so many places.
And as soon as we could use node again, we switched back.



signature.asc
Description: OpenPGP digital signature
-- 
Pkg-javascript-devel mailing list

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package [and 1 more messages]

[Ian Jackson]

Pirate Praveen writes ("Re: Javascript team policy and rejection of node-three 
binary package"):
> On ചൊവ്വ 06 മാർച്ച് 2018 07:42 വൈകു, Ian Jackson wrote:
> > This could be solved by dropping the nodejs dependency from all the
> > nodejs module packages and requiring top-level applications to depend
> > on nodejs.
> 
> I see two problems with that approach. 1. It makes these modules
> installable but unuseable in architectures where nodejs itself is not
> available.

I don't think 1 is a problem.

But:

> 2. We won't be able to specify a minimum version of nodejs for these
> modules.  For example, node-regexpu-core required nodejs >= 6 and
> this prevented its testing migration for a long time because testing
> only had nodejs 4 for a long time.

That is a problem, indeed.  Is this common ?
Another possibility, though would be to use Breaks.  Eg

 Package: node-regexpu-core
 Breaks: nodejs (<< 6~)

> I think separate binary should be allowed at least in the second case.

For me it's not a question of it being *allowed*.  I appreciate that a
lot of what is going on here must seem to you very much a question of
the Debian establishment wielding power.  But I would prefer to think
about what would be best.  If it is best to use another package then
it should not just be "allowed", but indeed encouraged, recommended or
mandated.

But I don't think we have quite explored all the issues yet.

> > Does handlebars contain anything that is useful to run directly ?
> 
> handlebars is templating system widely used, not only in nodejs. It has
> binding for different languages (like ruby-handlebars-assets) and also a
> command line interface. The command line can be used for compiling
> handlebars templates.

Right, so you said in the other branch of the thread.

Pirate Praveen writes ("Re: [Pkg-javascript-devel] Javascript team policy and 
rejection of node-three binary package"):
> On ചൊവ്വ 06 മാർച്ച് 2018 07:57 വൈകു, Ian Jackson wrote:
> > Is this going to be common ?  The Javascript ecosystem has large
> > numbers of small packages - but do they mostly contain just JS
> > libraries or do they generally all contain command line utilities
> > too ?
> 
> Libraries are majority, but there are many command line utilities too
> (mocha, uglifyjs, handlebars etc).

Right.

> > If only a much smaller number of upstream packages have command line
> > utilities, then we could have the number of JS .deb packages that need
> > to be maintained by putting the node and browser files into the same
> > package.
> 
> I think the following change to point 5 of javascript policy [1] has
> consensus now.

Woah, steady on there.  You only just posted this proposal.  It can't
possibly have consensus yet!  Furthermore, I was mostly asking
questions and exploring possibilities.

I appreciate that you are keen to move forward, but to that end I
would encourage you to engage quickly in this discussion, rather than
waiting a while and then providing a bunch of answers combined with
jumping straight to a policy change.

> Change,
> 
> 5. should generate a node-foo binary package if the script is usable
> also for Nodejs
> 
> to
> 
> 5. should provide node-foo and install package.json in
> /usr/lib/nodejs/foo if the script is usable also for Nodejs. If script
> includes a command line tool, it should generate foo (node-foo in case
> of a name conflict) binary package and declare dependency on nodejs. A
> separate binary package should be generated if the script requires a
> newer version of nodejs than available in testing to facilitate proper
> testing migration.

This would seem to suggest *three* packages in some cases ?  I'm not
sure I understand the intent.


Also your comments about namespace make me wonder: do many of these
node scripts have poorly chosen command names ?  Can I get a list of
them easily somehow ?

I don't think renaming the package only when there is a conflict is a
good rule of thumb.  Instead, the package should be renamed when
conflict is likely, even if it hasn't yet occurred.  The same goes for
command names.

I think "handlebars" and "uglify" are OK for this, but I don't know
what the whole ecosystem is like.  The controversy about the name
"node" itself, and upstream's handling of that, don't give me
confidence that the node.js upstream community have fully realised
that the command namespace is a global resource, which they should be
using with respect for others.

In practice, as an easier guideline, maybe it would be better to say
that the command and package should *usually* be renamed, unless the
script is high propfile and has a good name which is unlikely to
conflict.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are m

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package

[Pirate Praveen]

On ചൊവ്വ 06 മാർച്ച് 2018 07:57 വൈകു, Ian Jackson wrote:
> Simon is asking the same questions as I was earlier.  Sorry for
> posting before reading the whole thread.
> 
> Is this going to be common ?  The Javascript ecosystem has large
> numbers of small packages - but do they mostly contain just JS
> libraries or do they generally all contain command line utilities
> too ?

Libraries are majority, but there are many command line utilities too
(mocha, uglifyjs, handlebars etc).

> If only a much smaller number of upstream packages have command line
> utilities, then we could have the number of JS .deb packages that need
> to be maintained by putting the node and browser files into the same
> package.

I think the following change to point 5 of javascript policy [1] has
consensus now.

Change,

5. should generate a node-foo binary package if the script is usable
also for Nodejs

to

5. should provide node-foo and install package.json in
/usr/lib/nodejs/foo if the script is usable also for Nodejs. If script
includes a command line tool, it should generate foo (node-foo in case
of a name conflict) binary package and declare dependency on nodejs. A
separate binary package should be generated if the script requires a
newer version of nodejs than available in testing to facilitate proper
testing migration.

[1] https://wiki.debian.org/Javascript/Policy




signature.asc
Description: OpenPGP digital signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package

[Pirate Praveen]

On ചൊവ്വ 06 മാർച്ച് 2018 07:52 വൈകു, Ian Jackson wrote:
> I do think that the Javascript policy has to be not in a wiki page.
> We can't have normative references from debian-policy to wiki pages.
> 
> Pirate, is there some Debian-specific Javascript dev infrastructure
> package that could host this document ?

I think javascript-common or nodejs-dev could host it. nodejs-dev
already has the debhelper plugin for nodejs.



signature.asc
Description: OpenPGP digital signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package

[Pirate Praveen]

On ചൊവ്വ 06 മാർച്ച് 2018 07:42 വൈകു, Ian Jackson wrote:
> Pirate Praveen writes ("Javascript team policy and rejection of node-three 
> binary package"):
>> 1. Node.js has standard locations for discovering installed packages
>> which is different from browser targeted javascript libraries.
>>
>> Node.js expects pure js modules to be installed at /usr/lib/nodejs but
>> javascript libraries are installed at /usr/share/javascript
> 
> This is not an argument in favour of separate packages AFAICT ?

They are in two different directories because they target two different
APIs. Most of the time, files installed at /usr/lib/nodejs needs
browserification (webpacking/module bundling) to be able to be installed
at /usr/share/javascript. Though there are now formats like UMD
(Universal Module) which allows the code to be run in both environments.
I think in most cases where the software supports both environments, umd
modules are used, so it would be fine to provide a single binary
package. I just explained why these two separate targets exist.

>> 2. Dependency on nodejs is required only during build or when other
>> Node.js modules depend on it. a browser targeted library does not need
>> to depend on nodejs package.
> 
> This could be solved by dropping the nodejs dependency from all the
> nodejs module packages and requiring top-level applications to depend
> on nodejs.

I see two problems with that approach. 1. It makes these modules
installable but unuseable in architectures where nodejs itself is not
available. 2. We won't be able to specify a minimum version of nodejs
for these modules.

For example, node-regexpu-core required nodejs >= 6 and this prevented
its testing migration for a long time because testing only had nodejs 4
for a long time.

I think separate binary should be allowed at least in the second case.

>> If you take example of node-handlebars source package, libjs-handlebars
>> is targeted at browsers and does not need to declare a dependency on
>> nodejs. But handlebars package need nodejs to run. If there is only a
>> single binary package, nodejs will get installed unnecessarily.
> 
> Does handlebars contain anything that is useful to run directly ?

handlebars is templating system widely used, not only in nodejs. It has
binding for different languages (like ruby-handlebars-assets) and also a
command line interface. The command line can be used for compiling
handlebars templates.



signature.asc
Description: OpenPGP digital signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package

[Sean Whitton]

Hello Ian,

On Tue, Mar 06 2018, Ian Jackson wrote:

> Thanks for bringing this up, here.  FAOD, my primary intent in
> suggesting you do so was to get technicaly input from the denizens of
> d-policy, who have a lot of useful expertise.

Okay.  It's fine to use this list for that, of course.

I had interpreted Pirate's message as requesting the policy delegates do
something qua policy delegates.  Possibly this is because he
misinterpreted what you were suggesting.

> Many language-specific packaging teams have language-specific
> policies.  These are usually shipped in some core dev support package
> for the policy in question.  So far it has not been necessary to
> formally reference the Perl policy (say) from the debian-policy
> package.  But I don't see any reason why debian-policy could not
> formally refer to the Javascript policy.
>
> I do think that the Javascript policy has to be not in a wiki page.
> We can't have normative references from debian-policy to wiki pages.

Agreed.  Not everything needs to be in our package.

(It might aid in discoverability if team policies were published more
systematically, though, and perhaps incorporating them into our package
is the way to do that.  But that's a discussion for another day.)

-- 
Sean Whitton


signature.asc
Description: PGP signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package

[Ian Jackson]

Pirate Praveen writes ("Re: [Pkg-javascript-devel] Javascript team policy and 
rejection of node-three binary package"):
> On March 4, 2018 3:15:24 AM GMT+05:30, Simon McVittie <s...@debian.org> wrote:
> >For instance, src:tap.py builds python3-tap (the Python 3 library for
> >"import tap"), python-tap (the Python 2 library for "import tap") and
> >tappy (the tappy(1) command). If you did similar things for JavaScript,
> >you could have a handlebars package that depends on libjs-handlebars
> >and nodejs?
> 
> Yes, that is what I did.

Simon is asking the same questions as I was earlier.  Sorry for
posting before reading the whole thread.

Is this going to be common ?  The Javascript ecosystem has large
numbers of small packages - but do they mostly contain just JS
libraries or do they generally all contain command line utilities
too ?

If only a much smaller number of upstream packages have command line
utilities, then we could have the number of JS .deb packages that need
to be maintained by putting the node and browser files into the same
package.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package

[Ian Jackson]

Pirate Praveen writes ("Javascript team policy and rejection of node-three 
binary package"):
> 1. Node.js has standard locations for discovering installed packages
> which is different from browser targeted javascript libraries.
> 
> Node.js expects pure js modules to be installed at /usr/lib/nodejs but
> javascript libraries are installed at /usr/share/javascript

This is not an argument in favour of separate packages AFAICT ?

> 2. Dependency on nodejs is required only during build or when other
> Node.js modules depend on it. a browser targeted library does not need
> to depend on nodejs package.

This could be solved by dropping the nodejs dependency from all the
nodejs module packages and requiring top-level applications to depend
on nodejs.

> If you take example of node-handlebars source package, libjs-handlebars
> is targeted at browsers and does not need to declare a dependency on
> nodejs. But handlebars package need nodejs to run. If there is only a
> single binary package, nodejs will get installed unnecessarily.

Does handlebars contain anything that is useful to run directly ?

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package

[Ian Jackson]

Sean Whitton writes ("Re: Javascript team policy and rejection of node-three 
binary package"):
> On Fri, Mar 02 2018, Pirate Praveen wrote:
> > I think the policy is good and request debian policy team to endorse
> > it.

Thanks for bringing this up, here.  FAOD, my primary intent in
suggesting you do so was to get technicaly input from the denizens of
d-policy, who have a lot of useful expertise.

> The way forward is to add the JavaScript policy to the debian-policy
> package.  It would not be wise to add a single requirement to our
> document, with the rest of the JavaScript policy maintained elsewhere.

I agree that importing a single rule from the Javascript policy into
the debian-policy package is not sensible.  But there are is a lot of
precedent for policy documents being maintained outside debian-policy.
For example, the DEP-8 spec for debian/tests/control is in the
autopkgtest package.

Many language-specific packaging teams have language-specific
policies.  These are usually shipped in some core dev support package
for the policy in question.  So far it has not been necessary to
formally reference the Perl policy (say) from the debian-policy
package.  But I don't see any reason why debian-policy could not
formally refer to the Javascript policy.

I do think that the Javascript policy has to be not in a wiki page.
We can't have normative references from debian-policy to wiki pages.

Pirate, is there some Debian-specific Javascript dev infrastructure
package that could host this document ?

> If you want to go ahead and do this, please file a bug against
> debian-policy, with a patch that adds the JavaScript policy to our repo.
> (There wouldn't be much point in filing such a bug without a patch.)

Moving the Javascript policy to the debian-policy package might be
nice, but I don't think it needs to be on the critical path for
finalising and formally blessing the policy.

There are also reasons why it might not be a good idea.  Other
programming languages find it easier to maintain their
language-specific policies outside both the debian-policy package and
the policy mailing list.

On the third had, Javascript seems to face unusual challenges and may
need more support and intervention from our core policy team.

Thanks,
Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package

[Stuart Prescott]

Pirate Praveen wrote:

> md5sum /usr/share/javascript/backbone/backbone.js
> /usr/lib/nodejs/backbone/index.js
> 8a8d829617513f36185a0ab055d088ec 
> /usr/share/javascript/backbone/backbone.js
> 8a8d829617513f36185a0ab055d088ec  /usr/lib/nodejs/backbone/index.js

except

lrwxrwxrwx … /usr/lib/nodejs/backbone/index.js -> 
../../../share/javascript/backbone/backbone.js


(md5sum dereferences symlinks)



-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7


-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package

[Pirate Praveen]

On വെള്ളി 02 മാർച്ച് 2018 09:57 വൈകു, Jonas Smedegaard wrote:
> I generally read team policies with an implicit "...as long as it 
> doesn't conflict with the general Debian Policy".
> 
> Specifically, I read the "should" in above quote as "in most cases, but 
> not a "must".
> 
> We have in the Javascript team an old practice of avoiding duplicate 
> code: When code is same for Browsers and Nodejs, we ship the code in the 
> libjs-* package and have that package "Provides: " the nodejs package.

But it seems node-backbone is in exactly same situation as node-three
(and I'm sure there would be more such cases already in the archive).
Instead of using a symlink, you chose to duplicate the file in both
packages.

md5sum /usr/share/javascript/backbone/backbone.js
/usr/lib/nodejs/backbone/index.js
8a8d829617513f36185a0ab055d088ec  /usr/share/javascript/backbone/backbone.js
8a8d829617513f36185a0ab055d088ec  /usr/lib/nodejs/backbone/index.js

Should we remove node-backbone binary and convert it to provides? And
also do the same for all such cases?



signature.asc
Description: OpenPGP digital signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package

[Pirate Praveen]

On March 4, 2018 3:15:24 AM GMT+05:30, Simon McVittie  wrote:
>Am I right in saying that nodejs-handlebars (or libjs-handlebars or
>some
>such) contains both a command-line tool, handlebars(1) (or similar),
>and
>a library named handlebars for node.js?

Yes. handlebars binary package includes /use/bin/handlebars and 
/usr/lib/nodejs/handlebars

>If I understand correctly, best practice for such libraries in other
>languages (mandatory for C and recommended for Python/Perl/etc.) is
>that
>the command-line tool is a separate binary package, for better
>discoverability (and in the case of Python, to avoid causing random
>breakage for users of the command-line tool if it originally used the
>Python 2 interpreter and gets moved to Python 3 later).
>
>For instance, src:tap.py builds python3-tap (the Python 3 library for
>"import tap"), python-tap (the Python 2 library for "import tap") and
>tappy (the tappy(1) command). If you did similar things for JavaScript,
>you could have a handlebars package that depends on libjs-handlebars
>and nodejs?

Yes, that is what I did. But it was not acceptable to waldi, when discussing 
over irc. It was eventually accepted by another ftp master, but I think it 
better to clarify this situation in policy.

I have provided links to irc discussion in my first mail to this thread.

>smcv

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package

[Simon McVittie]

On Sat, 03 Mar 2018 at 19:53:42 +0530, Pirate Praveen wrote:
> What do you think about the case of handlebars? In that case I think a
> separate binary is required because the command line tool must declare a
> dependency on nodejs, whereas the javascript library (libjs-*), does not
> require it.

Am I right in saying that nodejs-handlebars (or libjs-handlebars or some
such) contains both a command-line tool, handlebars(1) (or similar), and
a library named handlebars for node.js?

If I understand correctly, best practice for such libraries in other
languages (mandatory for C and recommended for Python/Perl/etc.) is that
the command-line tool is a separate binary package, for better
discoverability (and in the case of Python, to avoid causing random
breakage for users of the command-line tool if it originally used the
Python 2 interpreter and gets moved to Python 3 later).

For instance, src:tap.py builds python3-tap (the Python 3 library for
"import tap"), python-tap (the Python 2 library for "import tap") and
tappy (the tappy(1) command). If you did similar things for JavaScript,
you could have a handlebars package that depends on libjs-handlebars
and nodejs?

smcv

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package

[Pirate Praveen]

On വെള്ളി 02 മാർച്ച് 2018 09:57 വൈകു, Jonas Smedegaard wrote:
> I generally read team policies with an implicit "...as long as it 
> doesn't conflict with the general Debian Policy".
> 
> Specifically, I read the "should" in above quote as "in most cases, but 
> not a "must".
> 
> We have in the Javascript team an old practice of avoiding duplicate 
> code: When code is same for Browsers and Nodejs, we ship the code in the 
> libjs-* package and have that package "Provides: " the nodejs package.

Thanks for this suggestion. I think this will solve this particular case
because webpack and gitlab already depend on nodejs and I don't have to
declare a nodejs dependency for libjs-three.

What do you think about the case of handlebars? In that case I think a
separate binary is required because the command line tool must declare a
dependency on nodejs, whereas the javascript library (libjs-*), does not
require it.




signature.asc
Description: OpenPGP digital signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package

[Pirate Praveen]

On വെള്ളി 02 മാർച്ച് 2018 09:25 വൈകു, Sean Whitton wrote:
> Hello,
> 
> On Fri, Mar 02 2018, Pirate Praveen wrote:
> 
>> I think the policy is good and request debian policy team to endorse
>> it.
> 
> The way forward is to add the JavaScript policy to the debian-policy
> package.  It would not be wise to add a single requirement to our
> document, with the rest of the JavaScript policy maintained elsewhere.
> 
> Note that this does require that the JavaScript policy is no longer
> "work in progress" (quoting the wiki page you reference).  The reason
> for this is that the process for making changes will become much longer
> than editing a wiki page (requiring seconds etc.), so we would want to
> ensure the policy is more complete than it is now.

Thanks, I will work with Javascript team and try to finalize it.

> If you want to go ahead and do this, please file a bug against
> debian-policy, with a patch that adds the JavaScript policy to our repo.
> (There wouldn't be much point in filing such a bug without a patch.)
> 

If/When I get a consensus from the team, I will file it.



signature.asc
Description: OpenPGP digital signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package

[Sean Whitton]

Hello,

On Fri, Mar 02 2018, Pirate Praveen wrote:

> I think the policy is good and request debian policy team to endorse
> it.

The way forward is to add the JavaScript policy to the debian-policy
package.  It would not be wise to add a single requirement to our
document, with the rest of the JavaScript policy maintained elsewhere.

Note that this does require that the JavaScript policy is no longer
"work in progress" (quoting the wiki page you reference).  The reason
for this is that the process for making changes will become much longer
than editing a wiki page (requiring seconds etc.), so we would want to
ensure the policy is more complete than it is now.

If you want to go ahead and do this, please file a bug against
debian-policy, with a patch that adds the JavaScript policy to our repo.
(There wouldn't be much point in filing such a bug without a patch.)

-- 
Sean Whitton


signature.asc
Description: PGP signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package

[Jonas Smedegaard]

Quoting Pirate Praveen (2018-03-02 15:26:40)
> Javascript maintainers team have evolved a policy for javascript 
> packages and it is available at 
> https://wiki.debian.org/Javascript/Policy
> 
> Its last point says,
> 5. should generate a node-foo binary package if the script is usable
> also for Nodejs

I generally read team policies with an implicit "...as long as it 
doesn't conflict with the general Debian Policy".

Specifically, I read the "should" in above quote as "in most cases, but 
not a "must".

We have in the Javascript team an old practice of avoiding duplicate 
code: When code is same for Browsers and Nodejs, we ship the code in the 
libjs-* package and have that package "Provides: " the nodejs package.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel