<div dir="ltr"><div><div><div><div><div>I would like to take a moment to point out that developing system software is different from developing web applications. The way systems software is developed and often deployed is different from web applications.<br><br></div>Horizon as it sits today appears to be web application development by systems software developers. This raises the barrier to entry for web application developers.<br><br></div>The approach being proposed moves horizon into the realm of web application technologies that web application people use today.<br><br></div>The debate as I'm reading it is about taking web application development processes and turning them into systems development processes which are often foreign to web application developers. How is this going to work out? How will web app people be willing to get involved? Why should this be treated the same?<br><br></div>Most of OpenStack is a systems problem. This piece is a little different. To make it successful should it get some wiggle room to work well in the space it's in?<br><br></div>Note, I'm not saying it should be insecure or anything like that. There are just different approaches.<br><div><div><div><div><div><br></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 13, 2014 at 1:11 PM, Donald Stufft <span dir="ltr"><<a href="mailto:donald@stufft.io" target="_blank">donald@stufft.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Nov 13, 2014, at 12:38 PM, Thomas Goirand <<a href="mailto:zigo@debian.org">zigo@debian.org</a>> wrote:<br>
><br>
> On 11/13/2014 10:56 PM, Martin Geisler wrote:<br>
>> Maybe a silly question, but why insist on this? Why would you insist on<br>
>> installing a JavaScript based application using your package manager?<br>
>><br>
>> I'm a huge fan of package managers and typically refuse to install<br>
>> anything globally if it doesn't come as a package.<br>
>><br>
>> However, the whole JavaScript ecosystem seems to be centered around the<br>
>> idea of doing local installations. That means that you no longer need<br>
>> the package manager to install the software -- you only need a package<br>
>> manager to install the base system (NodeJs and npm for JavaScript).<br>
><br>
> Yeah... Just like for Java, PHP, Perl, Python, you-name-it...<br>
><br>
> In what way Javascript will be any different from all of these languages?<br>
<br>
</span>Node.js, and npm in particular tends to solve the dependency hell problem<br>
by making it possible to install multiple versions of a particular thing<br>
and use them all within the same process. As far as I know the OS tooling<br>
doesn’t really handle SxS installs of the same thing in multiple versions<br>
very well, I think the closest that you can do is multiple separate packages<br>
with version numbers in the package name?<br>
<br>
In other words it’s entirely possible that a particular set of npm packages<br>
can not be resolved to a single version per library.<br>
<span class=""><br>
><br>
>> Notice that Python has been moving rapidly in the same direction for<br>
>> years: you only need Python and pip to bootstrap yourself. After getting<br>
>> used to virtualenv, I've mostly stopped installing Python modules<br>
>> globally and that is how the JavaScript world expects you to work too.<br>
><br>
> Fine for development. Not for deployments. Not for distributions. Or you<br>
> just get a huge mess of every library installed 10 times, with 10<br>
</span>> different versions, and then a security issue needs to be fixed…<br>
<br>
Eh, I wouldn’t say it’s not fine for deployments. Generally I find that<br>
the less I tie the things where I care about versions to my OS the happier<br>
my life gets. It’s not fine for distributions wanting to offer it though,<br>
that is correct.<br>
<span class=""><br>
><br>
>> So maybe the Horizon package should be an installer package like the<br>
>> ones that download fonts or Adobe?<br>
><br>
> This is a horrible design which will *never* make it to distributions.<br>
> Please think again. What is it that makes Horizon so special? Answer:<br>
> nothing. It's "just a web app", so it doesn't need any special care. It<br>
> should be packaged, just like the rest of everything, with .deb/.rpm and<br>
> so on.<br>
><br>
>> That package would get the right version of node and which then runs the<br>
>> npm and bower commands to download the rest plus (importantly and much<br>
>> appreciated) puts the files in a sensible location and gives them good<br>
>> permissions.<br>
><br>
> Fine for your development environment. But that's it.<br>
><br>
> Also, does your $language-specific-package--manager has enough checks so<br>
> that there's no man in the middle attack possible? Is it secured enough?<br>
> Can a replay attack be done on it? Does it supports any kind of<br>
> cryptography checks like yum or apt does? I'm almost sure that's not the<br>
> case. pip is really horrible in this regard. I haven't checked, but I'm<br>
> almost sure what we're proposing (eg: npm and such) have the same<br>
> weakness. And here, I'm only scratching security concerns. There's other<br>
> concerns, like how good is the dependency solver and such (remember: it<br>
> took *years* for apt to be as good as it is right now, and it still has<br>
> some defects).<br>
<br>
</span>As far as I’m aware npm supports TLS the same as pip does. That secures the<br>
transport between the end users and the repository so you can be assured<br>
that there is no man in the middle. Security wise npm (and pip) are about<br>
~95% (mad up numbers, but you can get the gist) of the effectiveness as the<br>
OS package managers.<br>
<span class=""><br>
><br>
> On 11/14/2014 12:59 AM, Martin Geisler wrote:<br>
>> It seems to me that it should be possible translate the node module<br>
>> into system level packages in a mechanical fashion, assuming that<br>
>> you're willing to have a system package for each version of the node<br>
>> module<br>
><br>
> Sure! That's how I do most of my Python modules these days. I don't just<br>
> create them from scratch, I use my own "debpypi" script, which generates<br>
> a template for packaging. But it can't be fully automated. I could<br>
> almost do it in a fully automated manner for PEAR packages for PHP (see<br>
> "debpear" in the Debian archive), but it's harder with Python and pip/PyPi.<br>
<br>
</span>I would be interested to know what makes Python harder in this regard, I<br>
would like to fix it.<br>
<span class=""><br>
><br>
> Stuff like debian/copyright files have to be processed by hand, and each<br>
> package is different (How to run unit tests? nose, testr, pytest? Does<br>
> it support python3? Is there a sphinx doc? How good is upstream short<br>
> and long description?). I guess it's going to be the same for Javascript<br>
> packages: it will be possible to do automation for some parts, but<br>
> manual work will always be needed.<br>
><br>
> On 11/14/2014 12:59 AM, Martin Geisler wrote:<br>
>> The guys behind npm has written a little about how that could work<br>
>> here:<br>
>><br>
>> <a href="http://nodejs.org/api/modules.html#modules_addenda_package_manager_tips" target="_blank">http://nodejs.org/api/modules.html#modules_addenda_package_manager_tips</a><br>
><br>
> It's fun to read, but very naive. First thing that is very shocking is<br>
> that arch independent things gets installed into /usr/lib, where they<br>
> belong in /usr/share. If that is what the NPM upstream produces, that's<br>
> scary: he doesn't even know how the FSHS (FileSystem Hierarchy Standard)<br>
> works.<br>
<br>
</span>I may be wrong, but doesn’t the FHS state that /usr/share is for arch<br>
independent *data* that is read only? I believe it also states that<br>
/usr/lib is for object files, libraries, and internal binaries. As far as<br>
I’m aware the things that npm installs are libraries the same as what<br>
pip installs and should go under /usr/lib yea?<br>
<span class="im HOEnZb"><br>
><br>
>> Has anyone written such wrapper packages? Not the xstatic system which<br>
>> seems to incur a porting effort -- but really a wrapper system that<br>
>> can translate any node module into a system package.<br>
><br>
> The xstatic packages are quite painless, from my view point. What's<br>
> painful is to link an existing xstatic package with an already existing<br>
> libjs-* package that may have a completely different directory<br>
> structure. You can then end-up with a forest of symlinks, but there's no<br>
> way around that. No wrapper can solve that problem either. And more<br>
> generally, a wrapper that writes a $distribution source package out of a<br>
> $language-specific package manager will never solve all, it will only<br>
> reduce the amount of packaging work.<br>
><br>
> Cheers,<br>
><br>
> Thomas Goirand (zigo)<br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</span><span class="im HOEnZb">---<br>
Donald Stufft<br>
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA<br>
<br>
<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>