Mike, 2017-07-15 5:34 GMT+02:00 Mike Gerwitz <m...@gnu.org>:
> On Fri, Jul 14, 2017 at 13:57:30 +0200, Jelle Licht wrote: > > Regardless, the biggest issue that remains is still that npm-land is > mired > > in cyclical dependencies and a fun-but-not-actually unique dependency > > resolving scheme. > > I still think the largest issue is trying to determine if a given > package and its entire [cyclic cluster] subgraph is Free. That's a lot > of manual verification to be had (to verify any automated > checks). npm's package.json does include a `license' field, but that is > metadata with no legal significance, and afaik _defaults_ to "MIT" > (implying Expat), even if there's actually no license information in the > repository. in my idea I would have build a database withh conditions for being non free forr every npm package. So we could have queried the database for questions like: is there any non free or non buildable package in the dependency tree of, say, the current Jquery ? So we could have focused on such problems before embarking in a demanding packaging process and then get struck by said problem along the way (withh the risk of loosing the work already done) You might remember my post of a few months back about an attempt of mine to crawl thhe npm registry and storing data found there. I used amz3's wrap around Wiredtiger and that was probably not the best choice as I run into some maturity problems (maturity both of the framewrok and my own maturity). And then I slacked a bit I also posted more recently about a research team that published a SPARQL endpoint containing data about the npm packages I thought it would be important but the feedback I collected was not exactly warm So I thought there must be some fundamental flaw in my way of thinking about a more data centric way of dealing with this Now I'm not sure what Jelle is talking about but any approach that cold be shared among at least 2 persons would be a progress, in my opinion. Jelle, please, say something more about whaht you're doing !
