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 ...

[David Naylor]

On Tuesday, 16 May 2017 09:23:13 Adam Weinberger wrote:
> > On 16 May, 2017, at 2:57, Rodrigo Osorio <rodrigo at osorio.me> wrote:
> > On 05/16/17 00:27, Adam Weinberger wrote:
> >>> On 15 May, 2017, at 16:05, Rodrigo Osorio <rodrigo at FreeBSD.org> wrote:
> >> What do all these ports do that npm doesn't already do, especially given
> >> that this will cause breakage for everybody with any of these modules
> >> installed globally?
> >> 
> >> # Adam
> > 
> > Hi Adam,
> > 
> > That's npm dependencies that need to be packages properly, I'll feel
> > unsafe if the port relies on npm to download external sources from github
> > during the packaging, without checking the integrity.
> > 
> > Of course, this could be an issue for peoples who deploys npm packages on
> > their own, but how can we handle this ? Maybe dep search path should be
> > set manually if you install unpackaged npm tools ?
> > 
> > I run a quick test, but apparently node uses in tree dependencies before
> > global.
> > 
> > Cheers
> > -- rodrigo
> 
> The point is that clean-css is already installable by "npm install
> clean-css" or "npm install -g clean-css". The reason there were no node
> modules in the ports tree is that npm handles node modules better, manages
> dependencies automatically, and doesn't break things.
> 
> My gut feeling is that these ports are not a good idea. There's currently no
> policy about node modules, so you didn't do anything wrong by adding them,
> but I don't think these ports are beneficial.

I think this covers a broader topic of should we "port" other "packages"
of software provided through an external mechanism, such as:
 1) pip (Python)
 2) nuget (.NET)
 3) cran (R)
 4) npm (Node.js)

All of the above provide there own ways to manage dependencies, to a greater 
or lesser extent.  

I think there are three motivators for including these "packages" as part of 
Ports:

 - Binaries: some of these "packages" require compiling, and thus need to be 
kept consistent with the broader ecosystem (i.e. Ports).  Keeping these 
"packages" as part of Ports will ensure consistency with the rest of the 
system's binaries.

 - Dependency: a "package" may be a dependency on a i) a binary "package", or 
ii) a program (i.e. some other port).  The dependant could either include the 
dependency, privately, or the dependency needs to move into Ports.  The latter 
is obviously better from a consistency and maintainability perspective.  

So, I advocate for the inclusion of these "packages" in Ports.  However, if 
pkg ever develops the ability to "bridge" with these other frameworks then an 
alternative approach could be warranted.  

Regards
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freebsd.org/pipermail/svn-ports-all/attachments/20170517/8ceed535/attachment.sig>