A couple thoughts (sorry, it's late here):
1. I'll repeat my call for a list (somewhere) of who OpenStack's "downstream
stakeholders" are. I'm in favor of our commitment of support and cooperation,
but providing openness and insight into who we're offering it to would be
awesome.
2. Bundling LESS vs. other means: If you think downstream packagers don't like
node... pretty much nobody packages LESS. The recommended way to install LESS
is actually with NPM (the Node Package Manager). We could install it that way,
but that makes dependency management even more complicated. The important bit
is that people need to use a relatively consistent version of LESS, otherwise
very hard-to-debug differences in parsing and feature support creep in. So the
options became "package the very small, similarly licensed binary" or "make the
dependency mess even larger than it has to be".
3. Why node.js/LESS vs. SASS/Ruby...
3a. I wish there was a great solution to this problem in Python. There just
isn't right now. So that leaves LESS and SASS as the two best tools out there.
Either one introduces a new language.
3b. LESS vs. SASS is partly a matter of preference, and partly a matter of
playing nice with previous choices Horizon has made (such as building on top of
Twitter's Bootstrap framework) which is written in LESS and allows us to do
nice clean imports, extensions, etc. LESS also plays nicely with Django apps
such as django-compressor which handles static media asset compression and
versioning, and can hook into the LESS compiler to dynamically generate the
final files.
3c. Node.js vs. Ruby: Looking out later in this release cycle and into future
cycles, there are capabilities that node.js can facilitate which Ruby (or
Python for that matter) simply can't. Node.js has proven itself to be
stupendously capable in terms of real-time communications and massive
parallelism. Node libraries like socket.io are quickly becoming part of the
permanent landscape on the web. So while it may seem silly to use node.js just
for CSS management here, in the longer term we have the potential to leverage
it immensely.
4. LESS for dev, commit compiled files: I veto'd this one in Horizon's
discussions. I've played this game being a committer for Django when we tried
to maintain both "development" and "production" versions of the admin's
javascript files. It was a nightmare trying to do due diligence on
contributions to make sure they were always in sync, etc. It's also an added
burden on the developers to understand this process and always adhere to
updating both files. All in all, not a scenario I support in any way shape or
form.
5. Client-side LESS vs. server-side LESS: If it is determined to be an
unreasonable burden to make node.js a hard requirement, I will admit we could
potentially hack a way to make node.js VERY STRONGLY recommended but optional
for those who simply will not/cannot install it. I, personally, would never
deploy LESS's client-side compilation code since it's a significantly worse
experience, but that's just me. That said, see point 3c for why we'll likely
have this discussion again in the future...
Finding the right balance is important here.
All the best,
- Gabriel
> -----Original Message-----
> From: [email protected]
> [mailto:openstack-
> [email protected]] On Behalf Of
> Thierry Carrez
> Sent: Friday, May 25, 2012 1:48 AM
> To: [email protected]
> Subject: Re: [Openstack] Nodejs in horizon
>
> Devin Carlen wrote:
> > -1 to introducing formal processes around this. This will happen from
> > time to time. Development may be briefly impacted on other platforms
> > but hindering innovation and telling developers that they are
> > responsible for package availability across every distro is not healthy.
>
> The PPB actually already ruled that new dependencies *need* to be
> discussed on the mailing-list prior to their introduction, if only so that
> downstream stakeholders learn about it and can work to solve it.
>
> Like others said, new dependencies impact our whole ecosystem and most
> of the time a small amount of discussion can go a long way in choosing a
> solution that is good for everyone, rather than firefighting after the fact.
>
> You are not responsible for package availability across every distro, but
> you're responsible for playing as nice with them as you can. That's the
> "Facilitation of downstream distribution" obligation of core projects[1], an
> obligation that the PPB can enforce.
>
> [1] http://wiki.openstack.org/ProjectTypes
>
> Regards,
>
> --
> Thierry Carrez (ttx)
> Release Manager, OpenStack
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : [email protected]
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
