"Maxime Vidori" <maxime.vid...@enovance.com> wrote: > >There is at least one bug open against Ubuntu[1], asking to install > >python-lesscpy as well, as customers "often" need to re-create or change > >stylesheets. > > > >This would imply nodejs in a production environment, when going back to > >less. > > As long as the css will be the only one included into the package, we cannot > run into this issue. If someone wants to modify the less file he could > compile it and just copy paste the result into the proper directory.
This doesn't sound particularly friendly, I think what Matthias was getting at is that there are requests from users who want to be able to modify the CSS directly. > >It seems a bit crazy to me to introduce NodeJS as a dependency just for > >the sake of an easy way to run jslint. There are other options > >available that run without NodeJS as a dependency. > > Sadly, the only solutions which try to implement jslint in pure python are in > alpha or abandoned. If you have a python library which has the same quality > as jslint (which is written by Douglas Crockford himself), I will be glad to > take a look at it. Sure, I'll look into it. There seems to be also Javascript-based solutions that could be viable. If anyone has recommendations based on past experience, please let me know. The patch Imre linked to looks like a good start! > >There are more implications to running NodeJS even only for > >development. It will likely have an impact on our infrastructure as > >well, since we'll want these checks running on patches up for > >review. Then if it's there for development it increases the risk it > >will creep in as a dependency for our runtime. > > That is a good point, but Selenium also provides external dependencies, like > a browser to run into. I do not really know the infrastructure used by > jenkins and how we can integrate our solution into, but I do not think it is > impossible (I have never got any trouble with the installation of node with > the sources in any distro). Selenium is already integrated with our Jenkins gate. I don't think it hurts either to run the tests in an environment similar to what they need to work in in the end. > >As for Selenium, are you talking about rewriting our existing Selenium > >tests in Javascript? If so I am opposed to this. The strength of our > >community is in Python, if we want to encourage people to write more > >tests we should make it easy for them to do so. > > Currently we have two Selenium tests in pure python, and all the others are > running in a page with qUnit, which is a javascript unit testing framework. > > Lastly, we will start using angularjs as a front-end framework, it provides > an advanced testing framework which allows us to get rid of selenium. I don't think Selenium is going away, and efforts have started around using it as well for our integration tests [0]. Looking at the current AngularJS patch up for review, it is testable without requiring NodeJS. From the initial mailing list discussion [1], my understanding is that we're planning on using a specific AngularJS feature, not rewriting everything with it. Changing our build system to accommodate this seems like getting a bit ahead of ourselves. Julie [0] https://blueprints.launchpad.net/horizon/+spec/selenium-integration-testing [1] http://lists.openstack.org/pipermail/openstack-dev/2013-November/018850.html _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
