From: Catonano <catonano@gmail.com>
To: Mike Gerwitz <mtg@gnu.org>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: npm (mitigation)
Date: Mon, 17 Jul 2017 11:45:29 +0200 [thread overview]
Message-ID: <CAJ98PDx4QqYjz3u-VNrxKTFDinVOVC6eD0LRkA5Zvs3UH3G79Q@mail.gmail.com> (raw)
In-Reply-To: <871spi5q5g.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 2056 bytes --]
Mike,
2017-07-15 5:34 GMT+02:00 Mike Gerwitz <mtg@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 !
[-- Attachment #2: Type: text/html, Size: 2662 bytes --]
next prev parent reply other threads:[~2017-07-17 9:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-14 8:52 npm (mitigation) Catonano
2017-07-14 11:57 ` Jelle Licht
2017-07-15 3:34 ` Mike Gerwitz
2017-07-15 3:57 ` Jelle Licht
2017-07-15 17:39 ` Adonay Felipe Nogueira
2017-07-15 16:51 ` Adonay Felipe Nogueira
2017-07-17 9:45 ` Catonano [this message]
2017-07-18 2:12 ` Mike Gerwitz
2017-07-17 9:28 ` Catonano
2017-07-24 15:39 ` Ricardo Wurmus
2017-07-25 6:37 ` Catonano
2017-07-14 17:11 ` Jan Nieuwenhuizen
2017-07-17 9:32 ` Catonano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJ98PDx4QqYjz3u-VNrxKTFDinVOVC6eD0LRkA5Zvs3UH3G79Q@mail.gmail.com \
--to=catonano@gmail.com \
--cc=guix-devel@gnu.org \
--cc=mtg@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).