Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 18 May 2017 09:48:08 -0600
From:      Adam Weinberger <adamw@adamw.org>
To:        David Naylor <naylor.b.david@gmail.com>
Cc:        Rodrigo Osorio <rodrigo@osorio.me>, Rodrigo Osorio <rodrigo@freebsd.org>, ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org
Subject:   Re: svn commit: r440978 - in head: devel devel/npm-amdefine devel/npm-clean-css devel/npm-clean-css/files devel/npm-commander devel/npm-commander/files devel/npm-graceful-readlink devel/npm-source-map ...
Message-ID:  <6CD1FD4D-5EF7-4562-84E3-FBA1825A0F01@adamw.org>
In-Reply-To: <1806880.NXCOkgnAQa@dragon.local>
References:  <201705152205.v4FM5kIw055373@repo.freebsd.org> <1917876.5GWQEAK6S8@dragon.local> <33786079-3935-478C-9F5B-9B46B4483CDB@adamw.org> <1806880.NXCOkgnAQa@dragon.local>

next in thread | previous in thread | raw e-mail | index | archive | help
> On 18 May, 2017, at 9:34, David Naylor <naylor.b.david@gmail.com> =
wrote:
>=20
> On Wednesday, 17 May 2017 20:53:35 Adam Weinberger wrote:
>> For these reasons, node modules and Go modules simply are not good
>> candidates for FreeBSD ports. npm manages node modules in the correct =
node
>> way (and pkg doesn't), and so npm is the correct way to install node
>> modules. I'm sure Go has a similar tool; I'll call it gopher because =
that
>> sounds like a good name for a Go installer, and I'm sure that it =
installs
>> Go modules the correct way, and so it is the correct way to install =
Go
>> modules.
>>=20
>> There are definitely exceptions to this: if a module must be modified =
in a
>> specific way to work on FreeBSD, or if a module is a required =
dependency of
>> another port, then having those modules in the tree definitely makes =
sense.
>=20
> Thank you for explaining your reasons, and for the better =
understanding of the=20
> intricacies of node packages (and npm). =20
>=20
> I think we are still stuck with the problem of needing a way to =
download the=20
> required npm files during the fetch phase (and have those files =
verified).

For a module, you simply download the tarball. For an app (see below), =
you'd be best off producing a bundle.

> For nuget we reproduced that logic in USES=3Dmono (which is simply =
download and=20
> extract).  There was the possibility to define a custom cache location =
from=20
> which nuget would do the extracting (and leave the downloading to the =
Ports=20
> framework), however I never got it to work.  I also think paket not =
work that=20
> way. =20
>=20
> Also, could you please clarify a point: Lets say I have a node package =
(say=20
> electron) that needs to be modified and compiled to run on FreeBSD.  =
It=20
> obviously has it's own node dependencies.  Will npm include those =
dependencies=20
> as private or would ports need to be created for them?  (My npm =
knowledge is=20
> next to non-existent.)

It will generally have its own node dependencies in a private tree of =
its own. And for that scenario, the required node modules should be =
bundled with the app itself. That's the whole idea behind the "new" =
paradigm: each app has separate copies of every module it needs, at =
exactly the version it wants.

> Also, some bike-shedding (dark blue please): In general, I am wary of =
the=20
> "new" way:
>=20
> - Consistency: if every program based on node.js bundled their own =
version of=20
> the library then updates are dependent on the software creator.  It is =
likely=20
> to have multiple versions (some with known issues/vulnerabilities) of =
a=20
> "package" to be installed.

Yes, and in fact that's the main feature of the design. Let's say your =
app depends on foo-1.0, bar-1.0, and baz-1.0. And let's say that bar and =
baz both want foo-2.0. You will wind up with the foo module installed =
three times, at two different versions.

Dependencies of an app are private to that app. Dependencies of a =
dependency are private to that dependency, and so on.

> - Alter-ability: there would no longer be a central place where one =
can make=20
> custom changes to a node package (for whatever reason) and have all =
users of=20
> that package automatically pick it up.

True, but there isn't one now either. If you have foo-1.0 installed =
globally (i.e. from a port), and then you run "npm install" (local) from =
some app or module, npm will preferentially install a new copy of foo =
locally, no matter the version.

The only way to actually fix that is to have the problem patched =
upstream.

For the ports under question, though, no modification is being done. =
These ports simply installed the node modules verbatim with the ports =
mechanism instead of the npm mechanism.

> These issues, however, are more "meta" in nature and are tangential to =
the=20
> practical issue of software propagation and deployment.

They're quite relevant questions, because they're new territory for us =
all. I'm glad you're asking them.

# Adam


--=20
Adam Weinberger
adamw@adamw.org
https://www.adamw.org




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6CD1FD4D-5EF7-4562-84E3-FBA1825A0F01>