From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jelle Licht Subject: Re: Cyclic npm dependencies Date: Sat, 24 Nov 2018 15:41:35 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000001b2df057b6af0f0" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59797) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gQa4D-0001wx-Qv for guix-devel@gnu.org; Sat, 24 Nov 2018 10:41:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gQa4A-0005BI-LC for guix-devel@gnu.org; Sat, 24 Nov 2018 10:41:57 -0500 Received: from mail1.fsfe.org ([217.69.89.151]:39390) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gQa4A-0004zX-A3 for guix-devel@gnu.org; Sat, 24 Nov 2018 10:41:54 -0500 Received: by mail-ot1-f48.google.com with SMTP id t5so12993779otk.1 for ; Sat, 24 Nov 2018 07:41:51 -0800 (PST) In-Reply-To: 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: swedebugia@riseup.net Cc: guix-devel --00000000000001b2df057b6af0f0 Content-Type: text/plain; charset="UTF-8" Hey swedebugia, I will still send a more elaborate reply to the general npm-importer thread later this week, but we can assume that generally these recursive dependencies can be untangled by looking at the different versions of the dependencies. So in your example, I imagine an input chain like: node-glob 0.1 -> node-rimraf 0.1 -> node-glob 0.2 -> node-rimraf 0.2 -> .... -> node-glob 1.0 -> node-rimraf 1.0 While *extremely* annoying to untangle, this is definitely doable. Problems arise if this chain does not actually exist, which basically means that we have to hunt down commits [1] which are steps in these chains. Another complication is the versioning scheme used by many npm packages, the semver [2] + ranges notation [3]. This makes this kind of 'versioning archeology' even harder to do. For the case where this chain does exist, I have been working on a semi-npm-compatible semver parser for guile [4], which I was hoping to integrate in the npm importer or a standalone tool to assist people wanting to untangle these dependency chains. The goal would be to reconstruct the needed versions to package by parsing data in the package.json files of historic versions of these packages. HTH, Jelle [1]: ... or even more granular, parts of commits! [2]: https://semver.org/ [3]: https://docs.npmjs.com/misc/semver [4]: https://git.fsfe.org/jlicht/guile-semver Op za 24 nov. 2018 om 15:10 schreef swedebugia : > Hi > > We need to wonder about what to do with cyclic dependencies. > > In the case below node-rimraf has node-glob in input and node-glob has > node-rimraf in NATIVE-input. > > I have no idea how to solve this. Both packages are by the same author. > > Same problem with jasmine and jasmine-core > > ~/guix-tree/pre-inst-env guix build -K node-rimraf > allocate_stack failed: Cannot allocate memory > Warning: Unwind-only `stack-overflow' exception; skipping pre-unwind > handler. > allocate_stack failed: Cannot allocate memory > Warning: Unwind-only `stack-overflow' exception; skipping pre-unwind > handler. > allocate_stack failed: Cannot allocate memory > Warning: Unwind-only `stack-overflow' exception; skipping pre-unwind > handler. > > > -- > Cheers Swedebugia > > --00000000000001b2df057b6af0f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey swedebugia,

I will still send a more elabo= rate reply to the general npm-importer
thread later this week, but we ca= n assume that generally these
recursive dependencies can be untangled by= looking at the different
versions of the dependencies.

So in you= r example, I imagine an input chain like:
node-glob 0.1=C2=A0 -> node= -rimraf 0.1 -> node-glob 0.2 -> node-rimraf 0.2 -> .... -> node= -glob 1.0 -> node-rimraf 1.0

While *extremely* annoying to untang= le, this is definitely doable.
Problems arise if this chain does not act= ually exist, which basically
means that we have to hunt down commits [1]= which are steps in these
chains. Another complication is the versioning= scheme used by many npm
packages, the semver [2] + ranges notation [3].= This makes this kind of
'versioning archeology' even harder to = do.

For the case where this chain does exist, I have been working on= a
semi-npm-compatible semver parser for guile [4], which I was hoping t= o
integrate in the npm importer or a standalone tool to assist peoplewanting to untangle these dependency chains. The goal would be to
recon= struct the needed versions to package by parsing data in the
package.jso= n files of historic versions of these packages.

HT= H,

Jelle

[1]: ... or even= more granular, parts of commits!
[2]: h= ttps://semver.org/
[3]: https://docs.npmjs.com/misc/semver
[4]: https://git.fsfe.org/jlicht/guile-semver

Op za 24 nov. 20= 18 om 15:10 schreef swedebugia <swedebugia@riseup.net>:
Hi<= br>
We need to wonder about what to do with cyclic dependencies.

In the case below node-rimraf has node-glob in input and node-glob has
node-rimraf in NATIVE-input.

I have no idea how to solve this. Both packages are by the same author.

Same problem with jasmine and jasmine-core

~/guix-tree/pre-inst-env guix build -K node-rimraf
allocate_stack failed: Cannot allocate memory
Warning: Unwind-only `stack-overflow' exception; skipping pre-unwind handler.
allocate_stack failed: Cannot allocate memory
Warning: Unwind-only `stack-overflow' exception; skipping pre-unwind handler.
allocate_stack failed: Cannot allocate memory
Warning: Unwind-only `stack-overflow' exception; skipping pre-unwind handler.


--
Cheers Swedebugia

--00000000000001b2df057b6af0f0--