maintaining packages in macports vs. in a language package manager

[Ryan Schmidt]

On Nov 17, 2017, at 01:40, Mojca Miklavec wrote:

> The npm is
> another example of this approach. We basically ignore javascript
> packages, but since this is mostly useful for web development, we are
> not really hurt.

npm has the additional complications that a module can specify what range of versions of a dependency it wants, and each module can install its own copy of its dependencies.

There are ways this could be handled in MacPorts. There could be an npm2port script that generates the portfile and a json file that lists the latest version of each dependency that satisfies the module's requirements; npm supports using such a json file. The maintainer would have to use the script every time the module is updated to update both the portfile and the json file. 

If we wanted to be able to mirror the dependencies' distfiles efficiently we would also want to implement the multiple dist_subdir feature recently discussed on the list. Or store all npm modules in a single dist_subdir like we do for perl modules, but that's kinda crappy. 

Mostly npm is used in web development and people have their own solutions for that so maybe we don't need to do all this. However we do have some possibly general purpose npm modules in MacPorts already, including jake and coffeescript, which I have not updated in years, because I haven't known how to handle their dependencies on other npm modules. They didn't have those dependencies when I added them to MacPorts. There might be other general purpose utilities that happen to be distributed via npm that we might want to have in MacPorts.