Open Stack

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?

> 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...

> 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).

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.

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.

> 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)