Re: Javascript team policy and rejection of node-three binary package
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
Re: Javascript team policy and rejection of node-three binary package [and 1 more messages]
Pirate Praveen writes ("Re: Javascript team policy and rejection of node-three
binary package [and 1 more messages]"):
> On വെള്ളി 09 മാർച്ച് 2018 04:48 വൈകു, Ian Jackson wrote:
> > [Pirate:]
> >> 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.
Right. Sorry, I had a bad reaction to "I think the following change
has consensus now". Normally the process is more like: discussion ->
outline suggestions -> proposals -> refinement -> consensus. By
definition a proposal only just posted cannot have consensus. I hope
this is clear.
I'm afraid I'm not in a position to answer your technical points now
because I'm travelling.
> I was traveling so could not reply earlier, the wait was not intentional.
Heh.
Regards,
Ian.
Re: Javascript team policy and rejection of node-three binary package [and 1 more messages]
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: Javascript team policy and rejection of node-three binary package [and 1 more messages]
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
Re: Javascript team policy and rejection of node-three binary package [and 1 more messages]
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 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.
