Re: Agora Octave: CSS preprocessors and continuous integration

[Wendy Liu]

On 10 August 2012 07:54, Mike Miller <address@hidden> wrote:

On Fri, Aug 10, 2012 at 1:31 AM, Wendy Liu wrote:
> Hi all,
>
> I've been working on implementation details for Agora Octave
> (http://dellsystem.me/posts/socis-2012-with-octave/), and I was hoping to
> hear some thoughts on the following topics:

Like Juan, I don't know anything about either one but what I've just
read following your links.

> CSS preprocessing with Less.js (http://lesscss.org/): Standard CSS syntax is
> very limited and lends itself to code duplication and disorganisation. To
> counter this, Less.js pre-processes CSS and brings in variables, mixins,
> nesting, and basic operations to the mix. It's released under the Apache
> license. I'm planning on using client-side compilation for debugging and
> then enabling server-side compilation in production. Anyone have any
> objections to or see potential problems with using Less.js?

I've only looked at the splash page, but this looks beneficial.

> Continuous integration: Unit tests are very helpful in a project of this
> complexity. As development proceeds and the codebase increases in size, so
> will the number of tests and so, too, will the time taken to run all the
> tests. After a while it will become too cumbersome to run the tests
> regularly, especially if we want to ensure compatibility with multiple
> versions of Django and/or Python. I'm this vein, I'm thinking of using
> Travis (http://travis-ci.org/) for automated unit testing management;
> however, I'd like to know if the community has other recommendations,
> particularly if there is integration with Mercurial.

Again, only what I've read in a few minutes, but AFAICT this locks you
in to git and github, correct? So the unit testing you are planning on
doing will only work on the github mirror repository? 

The only problem I have with that is if it requires significant hooks
in the source tree to get it to work with travis. If travis is
non-intrusive, all the configuration is on its side, I can still run
"make check" or equivalent on my own terms, then it's just an external
tool that doesn't affect anyone but you, like whichever editor or
shell you prefer, and I'd say you can do what you want.

If you want the rest of the community to benefit from a CI tool, then
it should be completely free and I should be able to stand up my own
instance anywhere I choose, and point it at the original mercurial
repository. From the admittedly limited reading I've done on travis,
this is not the case currently.

--
mike

Yes, it only works in conjunction with github. However, the only thing that travis really requires is a configuration file in which you can tell it what dependencies you need, what worker you want to run it on, and what command to run to execute the test script. The actual testing would be completely CI-platform-independent. In fact, you could always run it on your own machine (not `make check`, but `python manage.py test`), with the same results - Travis just obviates the need to do that. So it's really a non-intrusive, external tool (and I won't even need to add the Travis configuration file to the Mercurial repository).

On 10 August 2012 08:10, Jordi Gutiérrez Hermoso <address@hidden> wrote:

On 10 August 2012 01:31, Wendy Liu <address@hidden> wrote:
> Continuous integration: Unit tests are very helpful in a project of this
> complexity. As development proceeds and the codebase increases in size, so
> will the number of tests and so, too, will the time taken to run all the
> tests. After a while it will become too cumbersome to run the tests
> regularly, especially if we want to ensure compatibility with multiple
> versions of Django and/or Python. I'm this vein, I'm thinking of using
> Travis (http://travis-ci.org/) for automated unit testing management;
> however, I'd like to know if the community has other recommendations,
> particularly if there is integration with Mercurial.

Wendy, we have another CI tool for the GNU project. It's called Hydra:

    http://hydra.nixos.org/project/gnu

Maybe I'm stupid, but I don't think CI is all that important. I mean,
it's desirable, but not critical. Octave itself could benefit from CI
too, but since so many volunteers are regularly building it, we sort
of have our own crowdsourced CI system already. ;-)

If you decide to use CI for Agora, I would prefer that you write the
Hydra recipe (and it's VCS-agnostic, AFAICT). Here is an example for
Octave, but I don't know if it's actually correct:

    http://git.savannah.gnu.org/cgit/hydra-recipes.git/plain/octave/release.nix

That's true, it's definitely not critical, especially at this stage. It's just one of those additional tools that I think will improve the development process for Agora Octave.

I didn't know about Hydra. It looks interesting, although I can't find much information on it. Is it easy to integrate it with Python?

 

I like the idea of using a framework for CSS, so go right ahead with that.

HTH,
- Jordi G. H.

Great.