Thomas Goirand <z...@debian.org> writes: > On 11/14/2014 06:30 AM, Martin Geisler wrote: >> That is, I think Horizon developers will use these tools to produce a >> release -- a tarball -- and that tarball will be something you unpack >> on your webserver and then you're done. I base this on what I've seen >> in the project I've been working. The release tarball you download >> here don't mention npm, bower, or any of the other tools: >> >> https://github.com/zerovm/swift-browser/releases >> >> The tools were used to produce the tarball and were used to test it, >> but they're not part of the released product. Somewhat similar to how >> GCC isn't included in the tarball if you download a pre-compiled >> binary. > > When doing packages, I don't even use the tarball, but a git clone, > which itself produces an orig.tar.xz file. I do that to allow more > flexibility and to be able to do "upstream" code change easily.
That seems to be a choice you're making -- I think you could also use the upstream tarball as provided (let's say I also include unminified source files in the tarball). > On 11/14/2014 06:30 AM, Martin Geisler wrote: >> Maybe a difference is that you don't (yet) install a web application >> like you install a system application. Instead you *deploy* it: you >> unpack files on a webserver, you configure permissions, you setup >> cache rules, you configure a database, etc. > > I really don't see why a web application should be any different from > any other component of OpenStack. No, I wont "deploy" it, I will just > apt-get install it... I'm a long time Debian user and web developer. I install system tools (web servers, databases, editors) and I deploy web applications. I believe that's the most common way to handle web applications today. > On 11/14/2014 06:30 AM, Martin Geisler wrote: >> I agree that it would be cool to have web apps be as robust and >> general purpose as system apps. However, I think that day is a ways >> off. > > I'm not sure why you are saying this. Horizon works out of the box in > Debian, and so is murano-dashboard and the sahara support. That's cool! > On 11/14/2014 06:30 AM, Martin Geisler wrote: >> The dependency solver is as good as the community needs it to be. Or >> put differently, if the JavaScript community is able to produce >> working software with npm, then they obviously produce it within the >> bounds of the capabilities of its dependency solver. >> >> I'm happy to believe that apt has a top-notch and highly tuned >> dependency solver. That doesn't really matter since it would be >> solving problems we don't have. > > Dependency solving is pure math. It's very hard to get it right. I don't > agree that some language may need something weaker, and that it's > possible for the maintainers to adapt. It's just that it may, in some > case, be possible to go around some defects if they exist, but everyone > needs a robust dependency solver. I think you're misunderstanding the implication. If apt has a stronger dependency solver than npm, then that's fine. The argument that apt is stronger than npm is not an argument for moving node packages from npm to apt -- the Debian packages will still only use a subset of apt dependency solver, namely the subset they use with npm. > On 11/14/2014 06:30 AM, Martin Geisler wrote: >> In my view, you're taking on way too much work by going into those >> details. I don't think I need or want you do to anything more than >> repack the tarball that npm retrieves -- I don't think you should run >> tests or generate documentation. > > Of course, I need to run tests. That's a big part of the QA work, and I > will certainly not give-up on that. You will have a hard time convincing > anyone within the OpenStack community that it's OK to not run unit tests. That's not what I said: the OpenStack developers will continue to tests the software. I personally don't think it's the job of the downstream packagers to do this QA work. (It's of course cool to run the tests on the system installed by your packages -- that test run would then install the needed tools using npm and bower and whatnot if that's how the upstream has setup the test framework.) > On 11/14/2014 06:30 AM, Martin Geisler wrote: >> As a user or sysadmin, I would be happy to add a deb line to my >> sources.list and get Debian packages that wrap the node modules. > > This means that the packages would *not* be in Debian. Therefore, > horizon couldn't be uploaded to Debian (as there would be some not > available dependencies). That's absolutely not what I want to do. I > want Horizon, just like the rest of OpenStack, to be fully in Debian. You don't have to convince me -- I'm not going to deploy OpenStack anytime soon (apart from DevStack). So I'm not really the right customer for these packages. All I wanted to say is that if there is a cool OpenStack dashboard written as a web app, then I would be happy to deploy it like I deploy other web apps. If there were a package I could use, that would be cool, but it's by no means a show-stopper for someone like me. Organizations might have other rules and concerns. If they cannot install using npm, then I would expect them to roll their own simple packages that simply bundle the files installed by npm. In the end, such a dashboard would be a directory tree with a bunch of static HTML and JavaScript files (no references to npm after the build) and that can be packaged and installed quite easily. -- Martin Geisler http://google.com/+MartinGeisler
pgpi_27B9IgG0.pgp
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev