On Wed, Jul 09, 2014 at 03:56:36AM -0700, Vasily Mikhaylichenko wrote:
> I think the path of least resistance would be to follow the Node way and
> to patch dependencies on the application port level.
>
> Two different applications are likely to have very different dependency
> graphs given how tiny and fast changing some modules are. Worst case
> scenario, we'll end up copying patches between ports (which would be a
> good sign that something is wrong with the upstream).
>
> Another interesting problem is fixing the versions of the dependencies
> so that the port build is reproducible. And from my experience "npm
> shrinkwrap" doesn't always work.
>
> Taking a step back, isn't the ultimate goal just making all the
> important modules installable on OpenBSD from npm?
>
Hi,
after some experiments with node pkg's in the past i came up with an
idea i wanted to prototype but due to lack of time i didn't made any
progress.
The main goal was to install node packages via pkg tools under
${PREFIX}/lib/node_modules exactly like they would have been installed with
npm -g.
Bundling a node-module with all its dependencies into one package was
possible but had some drawbacks though:
- local patching was not possible in one of my experiments, and if it
would be possible, we had to copy patches between packages which would
become a mess.
If we do not want to bundle node-modules with its dependencies into one
package we could try to specify dependencies via RUN_DEPENDS like the rest of
the ports tree.
The main difference between node dependencies and other dependencies is
that node modules install their dependencies relative to their own
location in a recursive fashion.
What if the pkg tools would support something like 'relative packages' which
would let us specify a 'relative PREFIX' under which to install things.
Example:
pkg_add node-request
pkg_add node-someDepA:'node-request'
pkg_add node-someDepB:'node-request/node_modules/someDepA'
pkg_add node-someDepC:'node-request/node_modules/someDepA'
pkg_add node-someDepC:'node-request'
this would result in a directory tree like this:
${PREFIX}/lib/node_modules/
node-request/
node_modules/
node-someDepA/
node_modules/
node-someDepB/
node-someDepC/
node-someDepC/
Notice that a package could be installed multiple time (node-someDepC)
as long as their 'relative PREFIX' is different.
Node's relative packages would have a 'default relative prefix' like 'lib'
which is used when no relative prefix was provided (in this example
node-request
uses the 'default prefix', which is installed globaly in this example).
In their corresponding PLIST some or all package files are marked as 'relative'
and would install files under 'node_modules/PKGNAME/*'
At install time the absolute path would be
${PREFIX}/${RELPREFIX}/PLISTENTRY
Here's the idea i had in mind:
- create a package for each node module and a directory structure under
/usr/ports like this:
node/
node-request/
v1.2.0/
v1.3.0/
node-depA/
v0.0.1/
node-depB/
v0.1.0/
node-depC/
v0.2.3/
v0.3.0/
- in a ports Makefile define dependencies
NODE_DEPENDS = node-depA \
node-depC
- teach pkg tools something about 'relative packages'
- when installed, the pkg tools would pass the relative path to the
dependencies.
- install extra files (symbolic links to binaries/man pages) in case
the packages is installed under the 'default relative PREFIX' e.g.
the package is a global one.
Not sure if that make sense at all :)
Cheers,
Fabian
> On Wed, Jul 9, 2014, at 02:13 AM, Andrew Fresh wrote:
> > I've been working more on making it easier to port node things, but have
> > run into a bit of a conundrum on best practices.
> >
> > Node has very interesting ways in which it installs dependencies.
> >
> > https://www.npmjs.org/doc/files/npm-folders.html
> >
> > While it will look in ${PREFIX}/lib/node_modules for things, if the
> > version there doesn't happen to match what it is hoping for, or for some
> > other reason I don't understand yet, NPM will download and install a
> > different version into
> > ${PREFIX}/lib/node_modules/${module}/node_modules.
> >
> > I'm not quite sure what to make of this or how to handle it.
> >
> > The Node community seems to think that installing multiple copies is a
> > reasonable solution, "It's fine, really. They're tiny JavaScript
> > programs".
> >
> > http://blog.nodejs.org/2011/03/23/npm-1-0-global-vs-local-installation/
> >
> >
> >
> > My current idea is to figure out how to force all the dependences that
> > don't come with node itself into .../$module/node_modules and add these
> > as additional DISTFILES that we can convince NPM to use.
> >
> >
> > I believe this way we would target installing node applications rather
> > than development libraries, if someone wishes to develop in node, they
> > would likely be using npm to directly install their exact dependencies
> > into their local environment anyway instead of using the package tools.
> >
> >
> > One downside I can see right now is the size of node packages will get
> > bigger and if you install many node apps there may be a bunch of
> > duplicate code in /usr/local/lib/node_modules/*/node_modules.
> >
> > The biggest problem is that this makes patching dependencies difficult,
> > that is, if multiple node apps depend on node-pg, while we needed
> > patches for it, those patches would have been hard to handle
> > automatically.
> >
> >
> > How do other people handle these sorts of dependencies, specifically
> > with node-keybase?
> >
> >
> > l8rZ,
> > --
> > andrew - http://afresh1.com
> >
> > The power!!!! The nightmares!!!! The strange medication!!!!!!!!
> >
>
