maintaining packages in macports vs. in a language package manager

Ryan Schmidt ryandesign at
Fri Nov 17 08:20:40 UTC 2017

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.  

More information about the macports-dev mailing list