On 13 November 2014 09:35, Adam Young <ayo...@redhat.com> wrote:
> On 11/12/2014 03:03 AM, Matthias Runge wrote:
>
>> On 12/11/14 08:40, Richard Jones wrote:
>>
>> I believe the nodeenv method of installing node solves this, as it's
>>> entirely local to the development environment.
>>>
>> See below, this touches package build as well.
>>
>>>
>>> I will have to go through all dependencies and do a review, if
>>> those are
>>> acceptable for inclusion e.g in Fedora. The same is true for Thomas
>>> Goirand for inclusion in Debian.
>>>
>>> >
>>> > Petr Belanyi has added optional jshint install for js linting into
>>> > Horizon and it installs nodejs as it depends on it. Could this
>>> approach
>>> > work for our need of js tooling too? [1]
>>>
>>> Sigh, this nonsense doesn't go away? This is the third time the same
>>> issue comes up.
>>>
>>> jshint is NOT free software.
>>>
>>> https://github.com/jshint/jshint/blob/master/src/jshint.js#L19
>>>
>>>
>>> They're trying to resolve that https://github.com/jshint/
>>> jshint/issues/1234
>>>
>>> But regardless, jshint doesn't have to be installed from a Linux
>>> repository; it's usually installed using npm alongside the other node
>>> tools.
>>>
>>> Thanks for the pointer, this is good news!
>>
>> Regarding package managers, my POV is completely different. From a
>> distributor perspective, where customers expect everything provided from
>> a single source, I'm not using npm, pip etc. I'm packaging that stuff
>> properly before using it.
>>
>> There are companies out there, where security policy does not allow to
>> install software from a third party repository. pypi etc. are considered
>> as a third party here in this context.
>>
>> I would prefer to have the complete tool chain available as (RPM)
>> packages. I am executing unit tests etc. during package build. Our
>> builders don't have access to the internet, downloading any other stuff
>> from the internet is no option.
>>
>
> And this is really not-negotiable, too. Debian has the same requirements,
> it is not Red Hat/Fedora speciufic. It is no different than the Python
> Code. We dodn't pip install for RHOSP for the Python packages, and we
> can't use any of the language specific package managers.
>
> But, we are used to it, and dealing with package dependencies is what we
> do. Having these in Fedora, while painful, will be ultimately very
> valuable.
>
I guess a point of difference here is that the Linux packaging systems
target global installation, whereas bower and npm (in our case) target a
local installation. It's effectively vendoring the code, but you still have
to pull it down from a repository for each installation. Don't worry, I'm
not going to suggest we actually move back to vendoring :)
We're currently using xstatic and that works with Linux packaging because
it was designed to cope with being a global installation. The current
Horizon codebase has a django-xstatic plugin which further makes dealing
with xstatic components nicer - for example it handles path management and
static file compilation (JS minification and concatenation, for example).
That's really nice, but poses some problems:
- we would need to xstatic-ify (and deb/rpm-ify) all those components
- we could run into global version conflict issues if we run more than one
service on a system - is this likely to be an issue in practise though?
- as far as I'm aware, the xstatic JS minification is not angular-aware,
and will break angular code that has not been written to be
dumb-minifier-aware (the angular minifier "ngMin" is written in node and
knows how to do things more correctly); adding dumb-minifier-awareness to
angular code makes it ugly and more error-prone :/
On the minification issue though: I talked to a few people at the summit
and we agreed that minification should just be avoided; gzip at the
transport layer buys significantly better compression, and has the added
bonus that the resultant code is readable. I note that the Debian JS
guidelines* only recommend that libraries *should* be minified (though I'm
unsure why they even recommend that).
One further note on xstatic vs. bower: during development it's very useful
to be able to install random components from bower to try them out; during
angboard development I would sometimes install and remove half a dozen
components just in one day. I would hope that whatever solution we come up
with has at least some of this flexibility for experimentation.
Richard
* https://wiki.debian.org/Javascript/Policy
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
