Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package [and 1 more messages]
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.
Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package [and 1 more messages]
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.
Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package [and 1 more messages]
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-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: Javascript team policy and rejection of node-three binary package [and 1 more messages]
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.
Re: Javascript team policy and rejection of node-three binary package [and 1 more messages]
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
Re: Javascript team policy and rejection of node-three binary package [and 1 more messages]
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
Re: Javascript team policy and rejection of node-three binary package [and 1 more messages]
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 executa
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.
Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package
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
Re: Javascript team policy and rejection of node-three binary package
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
Re: Javascript team policy and rejection of node-three binary package
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
Re: Javascript team policy and rejection of node-three binary package
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
Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package
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 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 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.
Re: Javascript team policy and rejection of node-three binary package
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 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.
Re: Javascript team policy and rejection of node-three binary package
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 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.
Re: Javascript team policy and rejection of node-three binary package
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
Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package
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
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 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.
Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package
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
Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package
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
Re: Javascript team policy and rejection of node-three binary package
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
Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package
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
Re: Javascript team policy and rejection of node-three binary package
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
Re: Javascript team policy and rejection of node-three binary package
On Fri, Mar 02, 2018 at 07:56:40PM +0530, Pirate Praveen wrote: > Node.js expects pure js modules to be installed at /usr/lib/nodejs but > javascript libraries are installed at /usr/share/javascript Why should pure js module be in /usr/lib instead of /usr/share ? Cheers, -- Bill. Imagine a large red swirl here.
Javascript team policy and rejection of node-three binary package
[As suggested by Ian Jackson on -devel] [0] Hi, 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 But ftp masters rejected the last upload [1] which added node-three binary package to three.js source package. There was also a similar demand earlier about handlebars package [2] but was accepted by another ftp master. I think the policy is good and request debian policy team to endorse it. The advantages of creating different binary packages (hope others in the team can add any points I missed): 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 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. 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. [0] https://lists.debian.org/debian-devel/2018/03/msg00063.html [1] http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2018-February/025121.html [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837467#22 signature.asc Description: OpenPGP digital signature