Open Stack

> On Nov 13, 2014, at 12:38 PM, Thomas Goirand <zigo at debian.org> wrote:
> 
> On 11/13/2014 10:56 PM, Martin Geisler wrote:
>> Maybe a silly question, but why insist on this? Why would you insist on
>> installing a JavaScript based application using your package manager?
>> 
>> I'm a huge fan of package managers and typically refuse to install
>> anything globally if it doesn't come as a package.
>> 
>> However, the whole JavaScript ecosystem seems to be centered around the
>> idea of doing local installations. That means that you no longer need
>> the package manager to install the software -- you only need a package
>> manager to install the base system (NodeJs and npm for JavaScript).
> 
> Yeah... Just like for Java, PHP, Perl, Python, you-name-it...
> 
> In what way Javascript will be any different from all of these languages?

Node.js, and npm in particular tends to solve the dependency hell problem
by making it possible to install multiple versions of a particular thing
and use them all within the same process. As far as I know the OS tooling
doesn’t really handle SxS installs of the same thing in multiple versions
very well, I think the closest that you can do is multiple separate packages
with version numbers in the package name? 

In other words it’s entirely possible that a particular set of npm packages
can not be resolved to a single version per library.

> 
>> Notice that Python has been moving rapidly in the same direction for
>> years: you only need Python and pip to bootstrap yourself. After getting
>> used to virtualenv, I've mostly stopped installing Python modules
>> globally and that is how the JavaScript world expects you to work too.
> 
> Fine for development. Not for deployments. Not for distributions. Or you
> just get a huge mess of every library installed 10 times, with 10
> different versions, and then a security issue needs to be fixed…

Eh, I wouldn’t say it’s not fine for deployments. Generally I find that
the less I tie the things where I care about versions to my OS the happier
my life gets. It’s not fine for distributions wanting to offer it though,
that is correct.

> 
>> So maybe the Horizon package should be an installer package like the
>> ones that download fonts or Adobe?
> 
> This is a horrible design which will *never* make it to distributions.
> Please think again. What is it that makes Horizon so special? Answer:
> nothing. It's "just a web app", so it doesn't need any special care. It
> should be packaged, just like the rest of everything, with .deb/.rpm and
> so on.
> 
>> That package would get the right version of node and which then runs the
>> npm and bower commands to download the rest plus (importantly and much
>> appreciated) puts the files in a sensible location and gives them good
>> permissions.
> 
> Fine for your development environment. But that's it.
> 
> Also, does your $language-specific-package--manager has enough checks so
> that there's no man in the middle attack possible? Is it secured enough?
> Can a replay attack be done on it? Does it supports any kind of
> cryptography checks like yum or apt does? I'm almost sure that's not the
> case. pip is really horrible in this regard. I haven't checked, but I'm
> almost sure what we're proposing (eg: npm and such) have the same
> weakness. And here, I'm only scratching security concerns. There's other
> concerns, like how good is the dependency solver and such (remember: it
> took *years* for apt to be as good as it is right now, and it still has
> some defects).

As far as I’m aware npm supports TLS the same as pip does. That secures the
transport between the end users and the repository so you can be assured
that there is no man in the middle. Security wise npm (and pip) are about
~95% (mad up numbers, but you can get the gist) of the effectiveness as the
OS package managers.

> 
> On 11/14/2014 12:59 AM, Martin Geisler wrote:
>> It seems to me that it should be possible translate the node module
>> into system level packages in a mechanical fashion, assuming that
>> you're willing to have a system package for each version of the node
>> module
> 
> Sure! That's how I do most of my Python modules these days. I don't just
> create them from scratch, I use my own "debpypi" script, which generates
> a template for packaging. But it can't be fully automated. I could
> almost do it in a fully automated manner for PEAR packages for PHP (see
> "debpear" in the Debian archive), but it's harder with Python and pip/PyPi.

I would be interested to know what makes Python harder in this regard, I
would like to fix it.

> 
> Stuff like debian/copyright files have to be processed by hand, and each
> package is different (How to run unit tests? nose, testr, pytest? Does
> it support python3? Is there a sphinx doc? How good is upstream short
> and long description?). I guess it's going to be the same for Javascript
> packages: it will be possible to do automation for some parts, but
> manual work will always be needed.
> 
> On 11/14/2014 12:59 AM, Martin Geisler wrote:
>> The guys behind npm has written a little about how that could work
>> here:
>> 
>> http://nodejs.org/api/modules.html#modules_addenda_package_manager_tips
> 
> It's fun to read, but very naive. First thing that is very shocking is
> that arch independent things gets installed into /usr/lib, where they
> belong in /usr/share. If that is what the NPM upstream produces, that's
> scary: he doesn't even know how the FSHS (FileSystem Hierarchy Standard)
> works.

I may be wrong, but doesn’t the FHS state that /usr/share is for arch
independent *data* that is read only? I believe it also states that
/usr/lib is for object files, libraries, and internal binaries. As far as
I’m aware the things that npm installs are libraries the same as what
pip installs and should go under /usr/lib yea?

> 
>> Has anyone written such wrapper packages? Not the xstatic system which
>> seems to incur a porting effort -- but really a wrapper system that
>> can translate any node module into a system package.
> 
> The xstatic packages are quite painless, from my view point. What's
> painful is to link an existing xstatic package with an already existing
> libjs-* package that may have a completely different directory
> structure. You can then end-up with a forest of symlinks, but there's no
> way around that. No wrapper can solve that problem either. And more
> generally, a wrapper that writes a $distribution source package out of a
> $language-specific package manager will never solve all, it will only
> reduce the amount of packaging work.
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA