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>