[openstack-dev] [Horizon] the future of angularjs development in Horizon
martin at geisler.net
Thu Nov 13 16:31:46 UTC 2014
Thomas Goirand <zigo at debian.org> writes:
> Also, if the Horizon project starts using something like NPM (which
> again, is already available in Debian, so it has my preference), will we
> at least be able to control what version gets in, just like with pip?
Yes, npm similarly to pip in that you can specify the versions you want
to install. You can expect loose versions (like 1.2.x if you're okay
with gettting a random patch version) or you can specify the full
In parallel with that, you can add a "shrinkwrap" file which lists the
versions to install recursively. This locks down the versions of
indirect dependencies too (one of your dependencies might otherwise
depend on a loose version number).
> Because that's a huge concern for me, and this has been very well and
> carefully addressed during the Juno cycle. I would very much appreciate
> if the same kind of care was taken again during the Kilo cycle, whatever
> path we take. How do I use npm by the way? Any pointer?
After installing it, you can try running 'npm install eslint'. That will
create a node_modules folder in your current working directory and
install ESLint inside it. It will also create a cache in ~/.npm.
The ESLint executable is now
You'll notice that npm creates
and install the ESLint dependencies there. Try removing node_modules,
then install one of the dependencies first followed by ESLint:
rm -r node_modules
npm install object-assign eslint
This will put both object-assign and eslint at the top of node_modules
and object-assign is no longer in node_modules/eslint/node_modules/.
This works because require('object-assign') in NodeJS will search up the
directory tree until it finds the module. So the ESLint code can still
You can run 'npm dedupe' to move modules up the tree and de-duplicate
the install somewhat.
This nested module system also works the other way: if you run 'npm
install bower' after installing ESLint, you end up with two versions of
object-assign -- check 'npm list object-assign' for a dependency graph.
Surprisingly and unlike, say, Python, executing
can give you different modules depending on where the code lives that
execute the statement. This allows different parts of Bower to use
different versions of object-assign. This is seen as a feature in this
world... I fear that it can cause strange problems and bugs when data
travels from one part of the program to another.
So, the philosophy behind this is very different from what we're used to
with system-level package managers (focus on local installs) and even
From what we have in the Python world with pip (multiple versions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 818 bytes
Desc: not available
More information about the OpenStack-dev