From mboxrd@z Thu Jan 1 00:00:00 1970 From: Catonano Subject: Re: npm (mitigation) Date: Mon, 17 Jul 2017 11:45:29 +0200 Message-ID: References: <871spi5q5g.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c0da51263f51105548042ae" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52429) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dX2as-0005WY-JD for guix-devel@gnu.org; Mon, 17 Jul 2017 05:45:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dX2ar-0005HR-C2 for guix-devel@gnu.org; Mon, 17 Jul 2017 05:45:34 -0400 In-Reply-To: <871spi5q5g.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Mike Gerwitz Cc: guix-devel --94eb2c0da51263f51105548042ae Content-Type: text/plain; charset="UTF-8" Mike, 2017-07-15 5:34 GMT+02:00 Mike Gerwitz : > 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 ! --94eb2c0da51263f51105548042ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mike,

2017-07-15 5:34 GMT+02:00 Mike Gerwitz <= span dir=3D"ltr"><mtg@g= nu.org>:
On Fri, Jul 14, 2017 a= t 13:57:30 +0200, Jelle Licht wrote:
> Regardless, the biggest issue that remains is still that npm-land is m= ired
> in cyclical dependencies and a fun-but-not-actually unique dependency<= br> > resolving scheme.

I still think the largest issue is trying to determine if a given package and its entire [cyclic cluster] subgraph is Free.=C2=A0 That's = a lot
of manual verification to be had (to verify any automated
checks).=C2=A0 npm's package.json does include a `license' field, b= ut that is
metadata with no legal significance, and afaik _defaults_ to "MIT"= ;
(implying Expat), even if there's actually no license information in th= e
repository.

=C2=A0in my idea I would have b= uild 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 su= ch 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 al= ready done)

You might remember my post of a fe= w months back about an attempt of mine to crawl thhe npm registry and stori= ng data found there.

I used amz3's wrap around Wiredt= iger 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 recentl= y about a research team that published a SPARQL endpoint containing data ab= out the npm packages

I thought it would be important but = the feedback I collected was not exactly warm

So I though= t there must be some fundamental flaw in my way of thinking about a more da= ta 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 l= east 2 persons would be a progress, in my opinion.

Jelle,= please, say something more about whaht you're doing !
<= /div>
--94eb2c0da51263f51105548042ae--