[Camps-users] Integration with related projects
ethan at endpoint.com
Tue Dec 9 19:45:49 UTC 2008
Jon Jensen wrote:
> The results of integrating Camps, ControlTier, and Puppet are so far
> encouraging, and it's led me to consider whether this is a natural fit we
> should document and have a recommended integration recipe for.
> I'm interested in any comments you all have on that.
It does feel rather like they all go together, or ought to. Camps is
the missing piece of the puzzle between things like Puppet and Capistrano.
In Railsland at least, people are often fairly happy just developing on
a local instance on SQLite using webrick rather than a full Apache (or
other) web server; they don't try to solve the development environment
question beyond that, presumably because the apps are often small enough
that having absolutely consistency between production and development is
just not a pressing concern.
For bigger apps with a long production history, or for complex apps
where you have significant amounts of logic across multiple tiers in the
stack, it seems like having something like camps is an obvious need and
I would think companies that have embraced Puppet in particular would
have an interest.
> On another note, since Puppet and Capistrano are both written in Ruby, and
> we've been contemplating rewriting Camps for version 4 anyway, I've been
> thinking about whether it might make sense to write it in Ruby instead of
> Perl. That would let us leverage any Puppet or Capistrano libraries that
> would be useful, but it would also settle the question of which add-on
> object system to use in Perl (standard blessed hashes? Moose? Coat?) since
> Ruby's built-in object system would suffice and thus greatly reduce
> external dependencies. (We'd see the same advantage with Python.)
Ah, the language question.
I love Perl. I like Moose quite well. I'll also say that the Moose
object system is just not as fully-featured (which I guess amounts to
"not as good") as Ruby's basic object system. My Python experience is,
at this moment, too shallow for me to speak authoritatively to that end.
However, since the proposed redesign I outlined some months back
assumed object orientation, the object system is a concern.
Basic Perl objects are just not inspiring. Rolling one's own object
system is not a productive use of time and is similarly uninspiring.
Moose is quite a nice development for webapps, daemons, etc.. These
things are typically compiled fully at startup and then bear no further
compilation cost. For a family of command-line tools like the basic
camp interface, however, the idea of having a dependency like Moose
begins to smell; it means your command-line tools will probably never be
very snappy, because the compilation cost is paid every time and the
Moose module family is not insignificant. Any speed advantage Perl
might have over something like Ruby is out the window.
There are of course lighter-weight versions/derivatives of Moose that
may mitigate that cost. However, that strikes me as fairly speculative
at the moment.
I think chances are high that the stock object system in Ruby or Python
would be entirely sufficient for our needs, and would make the Perl
object system problem blessedly irrelevant. They are both expressive
tools, both widespread. Ruby has the advantage of potential easy
crossover with Puppet and Capistrano, as mentioned. I'm not sure that
need be a decisive factor, but it's a data point. Python is the
standard OS scripting/plumbing language of Red Hat, Google loves it,
etc., and has a well-established community with great free libraries out
there. Either could do very well.
The only major downside I see with moving to a language other than Perl,
other than my personal love for Perl of course, is the fact that it
means we cannot move incrementally. That's a fairly difficult issue to
overcome. My gut tells me that were this less of a concern, either
Python or Ruby could well be a better choice than Perl overall, my
aforementioned Perl affection aside.
I would be somewhat heartsick about moving beyond Perl for this and
think having to go at it from scratch is daunting (as far as a code base
is concerned; we're obviously not literally "from scratch" having built
the camp system already). On the other hand, the idea of doing it in
Python or Ruby and getting beyond Perl for things like the object system
feels right somehow.
End Point Corporation
ethan at endpoint.com
More information about the Camps-users