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 pac
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 JacksonThese 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.