From owner-svn-ports-all@freebsd.org Thu May 18 15:48:17 2017 Return-Path: Delivered-To: svn-ports-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 689DCD73F48; Thu, 18 May 2017 15:48:17 +0000 (UTC) (envelope-from adamw@adamw.org) Received: from apnoea.adamw.org (apnoea.adamw.org [104.225.5.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "apnoea.adamw.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B6DD1AE; Thu, 18 May 2017 15:48:14 +0000 (UTC) (envelope-from adamw@adamw.org) Received: by apnoea.adamw.org (OpenSMTPD) with ESMTPSA id f8fb30f0 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Thu, 18 May 2017 09:48:10 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) 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 ... From: Adam Weinberger In-Reply-To: <1806880.NXCOkgnAQa@dragon.local> Date: Thu, 18 May 2017 09:48:08 -0600 Cc: Rodrigo Osorio , Rodrigo Osorio , ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6CD1FD4D-5EF7-4562-84E3-FBA1825A0F01@adamw.org> References: <201705152205.v4FM5kIw055373@repo.freebsd.org> <1917876.5GWQEAK6S8@dragon.local> <33786079-3935-478C-9F5B-9B46B4483CDB@adamw.org> <1806880.NXCOkgnAQa@dragon.local> To: David Naylor X-Mailer: Apple Mail (2.3273) X-BeenThere: svn-ports-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 15:48:17 -0000 > On 18 May, 2017, at 9:34, David Naylor = 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