| Message ID | 1456233895-31812-1-git-send-email-atul.singh.mandla@rockwellcollins.com |
|---|---|
| State | Rejected |
| Headers | show |
On 02/23/16 14:24, Atul Singh wrote: > > --- > Signed-off-by: Atul Singh <atul.singh.mandla@rockwellcollins.com> > package/Config.in | 1 + > package/jsen/Config.in | 6 ++++++ > package/jsen/jsen.hash | 2 ++ > package/jsen/jsen.mk | 18 ++++++++++++++++++ > 4 files changed, 27 insertions(+) > create mode 100644 package/jsen/Config.in > create mode 100644 package/jsen/jsen.hash > create mode 100644 package/jsen/jsen.mk > > diff --git a/package/Config.in b/package/Config.in > index a5b31aa..6f8b8bd 100644 > --- a/package/Config.in > +++ b/package/Config.in > @@ -984,6 +984,7 @@ menu "External jQuery plugins" > source "package/jquery-validation/Config.in" > endmenu > endif > + source "package/jsen/Config.in" I wonder if this is really the correct place for it. This menu is for Javascript libraries that are installed in /var/www, i.e. that are meant to be used by web clients. AFAICS, however, jsen is meant to be used with nodejs (which is why it's installed in /usr/share, I guess). So I think we should create a new menu under the nodejs package: source "package/nodejs/Config.in" if BR2_PACKAGE_NODEJS menu "NodeJS libraries/modules" source "package/jsen/Config.in" endmenu endif I vaguely remember that this was discussed before - if so, the conclusion of that discussion should have been in your commit message. Regards, Arnout > source "package/jsmin/Config.in" > source "package/json-javascript/Config.in" > endmenu > diff --git a/package/jsen/Config.in b/package/jsen/Config.in > new file mode 100644 > index 0000000..8c41a19 > --- /dev/null > +++ b/package/jsen/Config.in > @@ -0,0 +1,6 @@ > +config BR2_PACKAGE_JSEN > + bool "jsen" > + help > + JSEN (JSON Sentinel) validates your JSON objects using JSON-Schema. > + > + https://github.com/bugventure/jsen > diff --git a/package/jsen/jsen.hash b/package/jsen/jsen.hash > new file mode 100644 > index 0000000..fdfcd93 > --- /dev/null > +++ b/package/jsen/jsen.hash > @@ -0,0 +1,2 @@ > +# Locally Computed > +sha256 651b3ae5c92865705c144175a8297305788a0e9a1f46ee9b8caa127c6bce6709 jsen-v0.6.0.tar.gz > diff --git a/package/jsen/jsen.mk b/package/jsen/jsen.mk > new file mode 100644 > index 0000000..535389d > --- /dev/null > +++ b/package/jsen/jsen.mk > @@ -0,0 +1,18 @@ > +################################################################################ > +# > +# jsen > +# > +################################################################################ > + > +JSEN_VERSION = v0.6.0 > +JSEN_SITE = $(call github,bugventure,jsen,$(JSEN_VERSION)) > +JSEN_LICENSE = MIT > +JSEN_LICENSE_FILES = LICENSE > + > +define JSEN_INSTALL_TARGET_CMDS > + mkdir -p $(TARGET_DIR)/usr/share/jsen > + $(foreach d,dist lib index.js,\ > + cp -dpfr $(@D)/$(d) $(TARGET_DIR)/usr/share/jsen/$(sep)) > +endef > + > +$(eval $(generic-package)) >
Arnout, On Tue, 23 Feb 2016 21:44:52 +0100, Arnout Vandecappelle wrote: > I wonder if this is really the correct place for it. This menu is for > Javascript libraries that are installed in /var/www, i.e. that are meant to be > used by web clients. AFAICS, however, jsen is meant to be used with nodejs > (which is why it's installed in /usr/share, I guess). So I think we should > create a new menu under the nodejs package: Atul originally placed jsen under the Libraries -> JSON/XML, and I suggested him to put it under the Javascript libraries. > source "package/nodejs/Config.in" > if BR2_PACKAGE_NODEJS > menu "NodeJS libraries/modules" > source "package/jsen/Config.in" > endmenu > endif If it's indeed a NodeJS package, then comes the question of how we are going to package those zillions of modules. Today, one can request any random NodeJS module to be installed using BR2_PACKAGE_NODEJS_MODULES_ADDITIONAL (which is simple, but obviously circumvents completely the download and legal infrastructures of Buildroot). Atul, are you using jsen in the context of NodeJS ? If not, in which context are you using it ? Thanks! Thomas
Arnout, Thomas, Atul, On Di, 2016-02-23 at 22:04 +0100, Thomas Petazzoni wrote: > Arnout, > > On Tue, 23 Feb 2016 21:44:52 +0100, Arnout Vandecappelle wrote: > > > > > I wonder if this is really the correct place for it. This menu is > > for > > Javascript libraries that are installed in /var/www, i.e. that are > > meant to be > > used by web clients. AFAICS, however, jsen is meant to be used with > > nodejs > > (which is why it's installed in /usr/share, I guess). So I think we > > should > > create a new menu under the nodejs package: > Atul originally placed jsen under the Libraries -> JSON/XML, and I > suggested him to put it under the Javascript libraries. > > > > > source "package/nodejs/Config.in" > > if BR2_PACKAGE_NODEJS > > menu "NodeJS libraries/modules" > > source "package/jsen/Config.in" > > endmenu > > endif > If it's indeed a NodeJS package, then comes the question of how we > are > going to package those zillions of modules. Today, one can request > any > random NodeJS module to be installed using > BR2_PACKAGE_NODEJS_MODULES_ADDITIONAL (which is simple, but obviously > circumvents completely the download and legal infrastructures of > Buildroot). > > Atul, are you using jsen in the context of NodeJS ? If not, in which > context are you using it ? Using BR2_PACKAGE_NODEJS_MODULES_ADDITIONAL should be the only way to install Node.js modules. Note that npm, the Node.js package manager takes care of all the package dependencies. In my opinion, this is the only sane way of installing Node.js modules for now. About legal infrastructure: for all installed Node.js packages the package.json file could be searched for the license information. Best regards Jörg Krause
Hello, On Thu, 25 Feb 2016 11:32:17 +0100, Jörg Krause wrote: > > Atul, are you using jsen in the context of NodeJS ? If not, in which > > context are you using it ? > > Using BR2_PACKAGE_NODEJS_MODULES_ADDITIONAL should be the only way to > install Node.js modules. Note that npm, the Node.js package manager > takes care of all the package dependencies. In my opinion, this is the > only sane way of installing Node.js modules for now. Thanks for raising your voice on this patch, it's definitely interesting to get some feedback. Since I'm not at all a NodeJS guy, I'm interested in having more details about: - Why you think the only sane way is to use BR2_PACKAGE_NODEJS_MODULES_ADDITIONAL as opposed to having proper packages for the different modules, like we do for the Perl, Python and Lua packages ? - What solution you propose to properly integrate this with the download and legal infrastructure of Buildroot. Right now, having "npm install" directly download and install stuff means that the download and legal-info infrastructure of Buildroot is completely worked-around. Due to this, "make source" will not download all the source, "make legal-info" will not list all the licenses, caching in BR2_DL_DIR doesn't work, BR2_PRIMARY_SITE doesn't work, etc. > About legal infrastructure: for all installed Node.js packages the > package.json file could be searched for the license information. Yes, but that's not integrated in the legal-info output, and doesn't solve the download infrastructure integration problem. At best, what this package.json file could help with, is help creating a script (much like scancpan) that automatically creates a Buildroot package for a given npm module. Best regards, Thomas
On Do, 2016-02-25 at 13:51 +0100, Thomas Petazzoni wrote: > Hello, > > On Thu, 25 Feb 2016 11:32:17 +0100, Jörg Krause wrote: > > > > > > > > > Atul, are you using jsen in the context of NodeJS ? If not, in > > > which > > > context are you using it ? > > Using BR2_PACKAGE_NODEJS_MODULES_ADDITIONAL should be the only way > > to > > install Node.js modules. Note that npm, the Node.js package manager > > takes care of all the package dependencies. In my opinion, this is > > the > > only sane way of installing Node.js modules for now. > Thanks for raising your voice on this patch, it's definitely > interesting to get some feedback. Since I'm not at all a NodeJS guy, > I'm interested in having more details about: > > - Why you think the only sane way is to use > BR2_PACKAGE_NODEJS_MODULES_ADDITIONAL as opposed to having proper > packages for the different modules, like we do for the Perl, > Python and Lua packages ? Because npm supports version ranges. Have a look at the example from the npm's docs [1]: { "dependencies" : { "foo" : "1.0.0 - 2.9999.9999" , "bar" : ">=1.0.2 <2.1.2" , "baz" : ">1.0.2 <=2.3.4" , "boo" : "2.0.1" , "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0" , "asd" : "http://asdf.com/asdf.tar.gz" , "til" : "~1.2" , "elf" : "~1.2.3" , "two" : "2.x" , "thr" : "3.3.x" , "lat" : "latest" , "dyl" : "file:../dyl" } } Lets take for example the dependency "boo". A package "A" may depend on version "2.0.1" whereas another package "B" may depend on version "2.3.x". In this case npm installs boo@2.0.1 in the subdirectory "node_modules" of package "A" and boo@2.3.4 (assume 2.3.4 is the most recent version for 2.3.x) in the subdirectory "node_modules" of package "B": {prefix}/lib/node_modules ├── A │ └── node_modules │ └── boo@2.0.1 └── B └── node_modules └── boo@2.3.4 As Buildroot does not support different versions for most of the packages I think we should only use npm to install Node.js packages. > - What solution you propose to properly integrate this with the > download and legal infrastructure of Buildroot. Right now, having > "npm install" directly download and install stuff means that the > download and legal-info infrastructure of Buildroot is completely > worked-around. Due to this, "make source" will not download all > the > source, "make legal-info" will not list all the licenses, caching > in > BR2_DL_DIR doesn't work, BR2_PRIMARY_SITE doesn't work, etc. I am not sure for now howto integrate this into the Buildroot infrastructure properly. I have never thought about this, but it will need some work to be done, I guess. > > > > About legal infrastructure: for all installed Node.js packages the > > package.json file could be searched for the license information. > Yes, but that's not integrated in the legal-info output, and doesn't > solve the download infrastructure integration problem. > > At best, what this package.json file could help with, is help > creating > a script (much like scancpan) that automatically creates a > Buildroot > package for a given npm module. I have never had a look at scancpan and I am not familiar with Perl packages, but looking at some META.json files, I guess it could be done similiar. Best regards Jörg Krause [1] https://docs.npmjs.com/files/package.json#dependencies
Jörg, Thanks for your feedback! On Thu, 25 Feb 2016 15:01:04 +0100, Jörg Krause wrote: > Because npm supports version ranges. Have a look at the example from > the npm's docs [1]: > > { "dependencies" : > { "foo" : "1.0.0 - 2.9999.9999" > , "bar" : ">=1.0.2 <2.1.2" > , "baz" : ">1.0.2 <=2.3.4" > , "boo" : "2.0.1" > , "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0" > , "asd" : "http://asdf.com/asdf.tar.gz" > , "til" : "~1.2" > , "elf" : "~1.2.3" > , "two" : "2.x" > , "thr" : "3.3.x" > , "lat" : "latest" > , "dyl" : "file:../dyl" > } > } > > Lets take for example the dependency "boo". A package "A" may depend on > version "2.0.1" whereas another package "B" may depend on version > "2.3.x". Gaah, this is horrible. > In this case npm installs boo@2.0.1 in the subdirectory "node_modules" > of package "A" and boo@2.3.4 (assume 2.3.4 is the most recent version > for 2.3.x) in the subdirectory "node_modules" of package "B": > > {prefix}/lib/node_modules ├── A > │ └── node_modules > │ └── boo@2.0.1 > └── B > └── node_modules > └── boo@2.3.4 > > As Buildroot does not support different versions for most of the > packages I think we should only use npm to install Node.js packages. Well, we can support this by having separate packages, but if they really break "boo" at every release and we need to package ten different versions of it, then it's a mess indeed. > > > - What solution you propose to properly integrate this with the > > download and legal infrastructure of Buildroot. Right now, having > > "npm install" directly download and install stuff means that the > > download and legal-info infrastructure of Buildroot is completely > > worked-around. Due to this, "make source" will not download all > > the > > source, "make legal-info" will not list all the licenses, caching > > in > > BR2_DL_DIR doesn't work, BR2_PRIMARY_SITE doesn't work, etc. > > I am not sure for now howto integrate this into the Buildroot > infrastructure properly. I have never thought about this, but it will > need some work to be done, I guess. If you don't have Buildroot packages, it will be nearly impossible I believe. > I have never had a look at scancpan and I am not familiar with Perl > packages, but looking at some META.json files, I guess it could be done > similiar. We have a similar script being worked on for Python, if you're familiar with Python. See for example http://patchwork.ozlabs.org/patch/501204/. Best regards, Thomas
Dear Thomas, sorry for very late reply! On Do, 2016-02-25 at 17:20 +0100, Thomas Petazzoni wrote: > Jörg, > > Thanks for your feedback! > > On Thu, 25 Feb 2016 15:01:04 +0100, Jörg Krause wrote: > > > > > Because npm supports version ranges. Have a look at the example > > from > > the npm's docs [1]: > > > > { "dependencies" : > > { "foo" : "1.0.0 - 2.9999.9999" > > , "bar" : ">=1.0.2 <2.1.2" > > , "baz" : ">1.0.2 <=2.3.4" > > , "boo" : "2.0.1" > > , "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0" > > , "asd" : "http://asdf.com/asdf.tar.gz" > > , "til" : "~1.2" > > , "elf" : "~1.2.3" > > , "two" : "2.x" > > , "thr" : "3.3.x" > > , "lat" : "latest" > > , "dyl" : "file:../dyl" > > } > > } > > > > Lets take for example the dependency "boo". A package "A" may > > depend on > > version "2.0.1" whereas another package "B" may depend on version > > "2.3.x". > Gaah, this is horrible. > > > > > In this case npm installs boo@2.0.1 in the subdirectory > > "node_modules" > > of package "A" and boo@2.3.4 (assume 2.3.4 is the most recent > > version > > for 2.3.x) in the subdirectory "node_modules" of package "B": > > > > {prefix}/lib/node_modules ├── A > > │ └── node_modules > > │ └── boo@2.0.1 > > └── B > > └── node_modules > > └── boo@2.3.4 > > > > As Buildroot does not support different versions for most of the > > packages I think we should only use npm to install Node.js > > packages. > Well, we can support this by having separate packages, but if they > really break "boo" at every release and we need to package ten > different versions of it, then it's a mess indeed. > > > > > > > > > > > - What solution you propose to properly integrate this with the > > > download and legal infrastructure of Buildroot. Right now, > > > having > > > "npm install" directly download and install stuff means that > > > the > > > download and legal-info infrastructure of Buildroot is > > > completely > > > worked-around. Due to this, "make source" will not download > > > all > > > the > > > source, "make legal-info" will not list all the licenses, > > > caching > > > in > > > BR2_DL_DIR doesn't work, BR2_PRIMARY_SITE doesn't work, etc. > > I am not sure for now howto integrate this into the Buildroot > > infrastructure properly. I have never thought about this, but it > > will > > need some work to be done, I guess. > If you don't have Buildroot packages, it will be nearly impossible I > believe. > > > > > I have never had a look at scancpan and I am not familiar with Perl > > packages, but looking at some META.json files, I guess it could be > > done > > similiar. > We have a similar script being worked on for Python, if you're > familiar > with Python. See for example http://patchwork.ozlabs.org/patch/501204 > /. > Unfortunatly, scanpypi does not work with latest Buildroot. But I tested scancpan and yes, I would say that we need something like this for Node.js and npm. However, the problem with dependencies of different versions is still there. For example Code-TidyAll depends on Moo whatever version. scanspan fetches latest Moo version 2.* and creates a fine buildroot package. The perl package Tropo however depends on Moo 1.*. Installing this package with scanspac afterwards does not change Moo, which is correct I think. However, building Tropo will use the package Moo 2.*, which might fail (I've not tested). Best regards Jörg Krause
Hello, On Mon, 28 Mar 2016 16:01:09 +0200, Jörg Krause wrote: > Unfortunatly, scanpypi does not work with latest Buildroot. Ah. It would be great if some of our Python contributors could take scanpipy, finish it and send it for merging. > But I > tested scancpan and yes, I would say that we need something like this > for Node.js and npm. However, the problem with dependencies of > different versions is still there. For example Code-TidyAll depends on > Moo whatever version. scanspan fetches latest Moo version 2.* and > creates a fine buildroot package. The perl package Tropo however > depends on Moo 1.*. Installing this package with scanspac afterwards > does not change Moo, which is correct I think. However, building Tropo > will use the package Moo 2.*, which might fail (I've not tested). This version-dependency thing is indeed a problem. For the specific case you point out, the solution would be to have separate moo1 and moo2 packages, very much like we do for python/python3, qt/qt5, etc. However, this is only realistic if there are only a few "major" versions for a few packages. If they break the API at every minor release, then it's clearly not doable. I personally don't really care about npm/node.js. Maybe we should just add a big fat legal warning in our legal information when NPM has been used to install additional packages, to explicitly say that those additions are not listed in the legal info output. This would at least warn the user. Best regards, Thomas
Thomas, On Mon, Mar 28, 2016 at 9:07 AM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > > Hello, > > On Mon, 28 Mar 2016 16:01:09 +0200, Jörg Krause wrote: > > > Unfortunatly, scanpypi does not work with latest Buildroot. > > Ah. It would be great if some of our Python contributors could take > scanpipy, finish it and send it for merging. > > > But I > > tested scancpan and yes, I would say that we need something like this > > for Node.js and npm. However, the problem with dependencies of > > different versions is still there. For example Code-TidyAll depends on > > Moo whatever version. scanspan fetches latest Moo version 2.* and > > creates a fine buildroot package. The perl package Tropo however > > depends on Moo 1.*. Installing this package with scanspac afterwards > > does not change Moo, which is correct I think. However, building Tropo > > will use the package Moo 2.*, which might fail (I've not tested). > > This version-dependency thing is indeed a problem. For the specific > case you point out, the solution would be to have separate moo1 and > moo2 packages, very much like we do for python/python3, qt/qt5, etc. > > However, this is only realistic if there are only a few "major" > versions for a few packages. If they break the API at every minor > release, then it's clearly not doable. > > I personally don't really care about npm/node.js. Maybe we should just > add a big fat legal warning in our legal information when NPM has been > used to install additional packages, to explicitly say that those > additions are not listed in the legal info output. This would at least > warn the user. Please reject this patch as we are not using it in the context of NodeJS but instead with HTML5 and JavaScript served up by a standard http server. We're ok with just maintaining it internally at this point. Thanks!
diff --git a/package/Config.in b/package/Config.in index a5b31aa..6f8b8bd 100644 --- a/package/Config.in +++ b/package/Config.in @@ -984,6 +984,7 @@ menu "External jQuery plugins" source "package/jquery-validation/Config.in" endmenu endif + source "package/jsen/Config.in" source "package/jsmin/Config.in" source "package/json-javascript/Config.in" endmenu diff --git a/package/jsen/Config.in b/package/jsen/Config.in new file mode 100644 index 0000000..8c41a19 --- /dev/null +++ b/package/jsen/Config.in @@ -0,0 +1,6 @@ +config BR2_PACKAGE_JSEN + bool "jsen" + help + JSEN (JSON Sentinel) validates your JSON objects using JSON-Schema. + + https://github.com/bugventure/jsen diff --git a/package/jsen/jsen.hash b/package/jsen/jsen.hash new file mode 100644 index 0000000..fdfcd93 --- /dev/null +++ b/package/jsen/jsen.hash @@ -0,0 +1,2 @@ +# Locally Computed +sha256 651b3ae5c92865705c144175a8297305788a0e9a1f46ee9b8caa127c6bce6709 jsen-v0.6.0.tar.gz diff --git a/package/jsen/jsen.mk b/package/jsen/jsen.mk new file mode 100644 index 0000000..535389d --- /dev/null +++ b/package/jsen/jsen.mk @@ -0,0 +1,18 @@ +################################################################################ +# +# jsen +# +################################################################################ + +JSEN_VERSION = v0.6.0 +JSEN_SITE = $(call github,bugventure,jsen,$(JSEN_VERSION)) +JSEN_LICENSE = MIT +JSEN_LICENSE_FILES = LICENSE + +define JSEN_INSTALL_TARGET_CMDS + mkdir -p $(TARGET_DIR)/usr/share/jsen + $(foreach d,dist lib index.js,\ + cp -dpfr $(@D)/$(d) $(TARGET_DIR)/usr/share/jsen/$(sep)) +endef + +$(eval $(generic-package))
--- Signed-off-by: Atul Singh <atul.singh.mandla@rockwellcollins.com> package/Config.in | 1 + package/jsen/Config.in | 6 ++++++ package/jsen/jsen.hash | 2 ++ package/jsen/jsen.mk | 18 ++++++++++++++++++ 4 files changed, 27 insertions(+) create mode 100644 package/jsen/Config.in create mode 100644 package/jsen/jsen.hash create mode 100644 package/jsen/jsen.mk