jsen: new package

---

Signed-off-by Atul Singh <[email protected]>

 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

package/Config.in +0 -0

index a5b31aa..6f8b8bd 100644

package/Config.in +0 -0

 	source "package/jsmin/Config.in"
 	source "package/json-javascript/Config.in"
 endmenu

package/jsen/Config.in new file +6 -0

new file mode 100644
index 0000000..8c41a19
@@ -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

package/jsen/jsen.hash new file +2 -0

new file mode 100644
index 0000000..fdfcd93
@@ -0,0 +1,2 @@
+# Locally Computed
+sha256  651b3ae5c92865705c144175a8297305788a0e9a1f46ee9b8caa127c6bce6709  jsen-v0.6.0.tar.gz

package/jsen/jsen.mk new file +18 -0

new file mode 100644
index 0000000..535389d
@@ -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))

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

Arnout,

Quoted 10 lines · Arnout Vandecappelle

?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.

Quoted 7 lines

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 ?

Quoted 2 lines

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.

Hello,

Quoted 11 lines · J?rg Krause

Quoted 5 lines

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.

Quoted 3 lines

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.

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 at 2.0.1 in the subdirectory "node_modules" of package "A" and boo at 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 at 2.0.1
???? B
? ? ???? node_modules
? ? ? ? ???? boo at 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.

Quoted 10 lines

?- 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.

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.

J?rg,

Thanks for your feedback!

Quoted 21 lines · J?rg Krause

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"
? }
}

Quoted 4 lines

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.

Quoted 14 lines

In this case npm installs boo at 2.0.1 in the subdirectory "node_modules"
of package "A" and boo at 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 at 2.0.1
???? B
? ? ???? node_modules
? ? ? ? ???? boo at 2.3.4

Quoted 3 lines

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.

Quoted 17 lines

Quoted 17 lines

?- 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.

Quoted 4 lines

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.

Quoted 1 line

Quoted 4 lines

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).

Hello,

Quoted 1 line · J?rg Krause

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.

Quoted 9 lines

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.