unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / Atom feed
* wip-node-14 branch
@ 2020-10-23 22:16 Jelle Licht
  2020-10-25 11:46 ` Pierre Neidhardt
  2020-11-06  8:39 ` Ludovic Courtès
  0 siblings, 2 replies; 4+ messages in thread
From: Jelle Licht @ 2020-10-23 22:16 UTC (permalink / raw)
  To: guix-devel

Hey Guix!

Depending on whom you ask, I come with what I see as good news! I just
pushed a series of patches with the long-term goal of getting the
Node.js situation in guix unstuck. You may find it on the `wip-node-14'
branch on on Savannah.

First things first: most of the hard work has been done by others. I'd
like to specifically thank Timothy Sample for their
`other-node-build-system' and Ryan Prior for getting `esbuild' packaged
and telling me about it. A shout out goes to Giacomo Leidi for making me
grumpy enough with the existing node-build-system to finally sit down
and fix this. I added Timothy as a Co-author on the first commit, so I
hope that is Good Enough for the copyright situation.

The branch contains the following changes:

- A revised `node-build-system', shelling out to `npm' for pretty much all
  phases of building a package. This also solves some inconsistencies
  our way of installing node packages lead to before [0]. It makes the
  current npm packages a bit more verbose, but if we ever end up with
  'properly' built npm packages, they should be easy to write.

- For now, I took the most recent Node.js package we had available that
  we could still build from source, and arbitrarily made an alias for it
  dubbed `node-bootstrap'.

- I used `esbuild' and some good old fashioned distro-packager moxie to
  bend the packages we need to run `llhttp's TypeScript and generate C
  files. I have also verified that the generated C files are identical
  to what is distributed upstream.

- I added a libuv-node package that tracks libuv upstream at a pretty
  fast pace. Help wanted on how/where/if we should manage this.

- ... and then I packaged Node.js version 14.14, which should last us
  for a good couple of years :-).


Some open issues/challenges:
- We used to patch out references to bundled dependencies in Node.js; this
  is no longer easily possible in some cases, although I have verified
  that the `--shared-XXX' flags do work; in practice this just means we
  waste some space in storing the sources for Node.js 14.

- There is a wrapper in use by Node.js for libuv called uvwasi; Once [1]
  is closed, we should look into packaging and subsequently unbundling
  this.

- Currently it is not possible to build a shared-library of `llhttp'[2]:
  I currently worked around this by generated both the sources and
  static library of `llhttp', and copying over our generated
  `llhttp.{c,h}' into the Node.js sourcetree. It works, but it ain't
  pretty. Once we can build llhttp as a shared library and Node.js
  supports a `--shared-llhttp' configure flag, we should do that.

- There are two (disabled) tests with a "TODO" comment above them. As a
  result of me not being clever enough and my laptop not being fast
  enough to compensate, I have not been able to figure why these tests
  fail (and if that is a problem in practice).

- There is _a lot_ of almost-duplication going on between our `node' and
  `node-14.14' packages; I don't like it whatsoever.

As a small extra, I have also worked on getting Timothy Sample's
'binary' npm importer to work with the contemporary guix import and
guile-json APIs; I'd like some insight into whether this binary importer
could still hold some value for inclusion in guix proper[3]. I could
still add this code to the branch as well if there is interest.

I won't be able to commit significant chunks of time on my end in the
upcoming month, but I've learned that it makes sense to share once you
have something worth sharing, instead of when you think it's
done. Reviews, tests and improvements very much welcome! I don't think
it makes sense to still target the upcoming release for all of this fun
stuff to be merged into master, but if somebody want to pick up the
slack and champion that cause; go right ahead!

Thanks!

 - Jelle

[0]: http://issues.guix.gnu.org/41219
[1]: https://github.com/nodejs/node/issues/35339
[2]: https://github.com/nodejs/llhttp/issues/52
[3]: http://logs.guix.gnu.org/guix/2020-10-23.log#123831


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: wip-node-14 branch
  2020-10-23 22:16 wip-node-14 branch Jelle Licht
@ 2020-10-25 11:46 ` Pierre Neidhardt
  2020-11-06  8:39 ` Ludovic Courtès
  1 sibling, 0 replies; 4+ messages in thread
From: Pierre Neidhardt @ 2020-10-25 11:46 UTC (permalink / raw)
  To: Jelle Licht, guix-devel

[-- Attachment #1: Type: text/plain, Size: 139 bytes --]

Wow, fantastic work you've pulled off!  Thank you so much and
congratulation to you all!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: wip-node-14 branch
  2020-10-23 22:16 wip-node-14 branch Jelle Licht
  2020-10-25 11:46 ` Pierre Neidhardt
@ 2020-11-06  8:39 ` Ludovic Courtès
  2020-11-16 10:03   ` Jelle Licht
  1 sibling, 1 reply; 4+ messages in thread
From: Ludovic Courtès @ 2020-11-06  8:39 UTC (permalink / raw)
  To: Jelle Licht; +Cc: guix-devel

Hi!

Jelle Licht <jlicht@fsfe.org> skribis:

> First things first: most of the hard work has been done by others. I'd
> like to specifically thank Timothy Sample for their
> `other-node-build-system' and Ryan Prior for getting `esbuild' packaged
> and telling me about it. A shout out goes to Giacomo Leidi for making me
> grumpy enough with the existing node-build-system to finally sit down
> and fix this. I added Timothy as a Co-author on the first commit, so I
> hope that is Good Enough for the copyright situation.

Woow, well done!

> As a small extra, I have also worked on getting Timothy Sample's
> 'binary' npm importer to work with the contemporary guix import and
> guile-json APIs; I'd like some insight into whether this binary importer
> could still hold some value for inclusion in guix proper[3]. I could
> still add this code to the branch as well if there is interest.

I think it would make sense to include this importer.  The manual should
warn about the fact that it does not yield built-from-source packages
and perhaps give pointers on how to address that, but it can still be
useful, and probably even more useful if it’s in Guix proper.

Thoughts?

> I won't be able to commit significant chunks of time on my end in the
> upcoming month, but I've learned that it makes sense to share once you
> have something worth sharing, instead of when you think it's
> done. Reviews, tests and improvements very much welcome! I don't think
> it makes sense to still target the upcoming release for all of this fun
> stuff to be merged into master, but if somebody want to pick up the
> slack and champion that cause; go right ahead!

I think the key is to avoid bitrot: I suggest working to make sure you
can have that branch merged within, say, one or two months at most, even
if that means regularly pinging people.  :-)

Thanks!

Ludo’.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: wip-node-14 branch
  2020-11-06  8:39 ` Ludovic Courtès
@ 2020-11-16 10:03   ` Jelle Licht
  0 siblings, 0 replies; 4+ messages in thread
From: Jelle Licht @ 2020-11-16 10:03 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

Ludovic Courtès <ludo@gnu.org> writes:

> Jelle Licht <jlicht@fsfe.org> skribis:
>
>> As a small extra, I have also worked on getting Timothy Sample's
>> 'binary' npm importer to work with the contemporary guix import and
>> guile-json APIs; I'd like some insight into whether this binary importer
>> could still hold some value for inclusion in guix proper[3]. I could
>> still add this code to the branch as well if there is interest.
>
> I think it would make sense to include this importer.  The manual should
> warn about the fact that it does not yield built-from-source packages
> and perhaps give pointers on how to address that, but it can still be
> useful, and probably even more useful if it’s in Guix proper.
>
> Thoughts?

Agreed! I still need to rework some of the recursive importer-related
plumbing in Guix proper for everything to play nicely with the multitude
of versions of packages that are required for pretty much anything.

 - Jelle


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-11-16 10:03 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-23 22:16 wip-node-14 branch Jelle Licht
2020-10-25 11:46 ` Pierre Neidhardt
2020-11-06  8:39 ` Ludovic Courtès
2020-11-16 10:03   ` Jelle Licht

unofficial mirror of guix-devel@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/guix-devel/0 guix-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guix-devel guix-devel/ https://yhetil.org/guix-devel \
		guix-devel@gnu.org
	public-inbox-index guix-devel

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.gnu.guix.devel
	nntp://news.gmane.io/gmane.comp.gnu.guix.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git