[xen-tools] Re: More changes

[C.J. Adams-Collier]

On 9/5/07, Steve Kemp <steve at steve.org.uk> wrote:
> On Wed Sep 05, 2007 at 07:52:08 -0700, C.J. Adams-Collier wrote:
>
> > Yes.  I agree.  Dependencies are often difficult to deal with.
>
>   Especially for non-Debian distributions I find.. but that could
>  just be bias. I think that other users are more used to using CPAN
>  directly.

You're right.  Debian has always been the forerunner in dependency
management.  The CPAN also has dependency handling functionality.  I
think that perhaps yum does as well, but it's been pretty terrible in
the past.  IMHO, the benefit of a standard object model outweights the
cost to the user of running

$ PERL_MM_USE_DEFAULT=1 perl -MCPAN -e 'install Moose'
or
$ sudo apt-get install libperl-moose

> > However, based on my review of your code, using Moose could reduce
> > your codebase size by nearly 40% and will make it much easier to
> > extend.
>
>   In general thats pretty good.  But specifically it's a little
>  hard to think of ways the code *should* be extended.  Most of it
>  is complete, if you see what I mean?

I understand where you are coming from.  However, the code is
currently a good start, but it is not ready for production in terms of
unit test coverage, extensibility, modularization, maintainability,
documentation, and others.  You have done a commendable job getting
the project on its feet, but (IMHO) you need to provide your users the
ability to extend the software in ways you have not considered.  If
the right hooks are put in place, your users will be able to override
pieces of the package without needing to bother you.

I've been realizing over the last few years that I am not capable of
doing everything that I want to see done in this life.  One way to see
that the most possible gets done is to provide a platform on which
like minded folk can collaborate and document the procedure.  This is
what I am referring to when I recommend making the software
extensible.

> > I see where you're coming from.  However, as a rule, people who read
> > Perl code expect to see a Makefile.PL or Build.PL, a MANIFEST file and
> > a META.yml in the root of the distribution.  The same thing is done in
> > all modern CPAN code.  I argue that providing the standard
> > distribution layout increases, not decreases readability.
>
>   Sure.  My objection is that the fact the code is in perl is
>  irrelevent to 99% of users, it is an implementation detail.
>
>   People install the software because they want to create new
>  xen guests easily.  So ultimately they only need 'make install',
>  and probably 97% of them don't touch anything else.

Why do users need a make install?  99.9% of users will be installing
this software via their distribution's installation mechanism.  The
only folks who look at this source package will be those interested in
extending or packaging it for a third party vendor.

>   If we could have a system that would work for both of us but
>  would also keep the top-level clean I'd be extremely happy.

This sounds good to me.  Maintaining a patch to the official version
sounds like the way to go in this case.  Please keep regular release
branches, as this will add complexity, overhead and a need for
synchronization.  CVS tags will allow me to keep the patch current
with the most important versions of the source.

> > Swig makes it possible to call perl from C, but it doesn't make it
> > easy to define classes in Perl.  Historically, there has been a lot of
> > hand waving and behind-the-curtain hiding involved with OO perl.
> > Moose cleans a lot of this up.
>
>   Good catch.
>
> > Yipe!  Your example has no type checking and provides no
> > encapsulation.
>
>   True on type checking, but that could be added if required.  As
>  for encapsulation with a couple of getter/setter methods it is
>  good enough...

Yes, all of these features could be re-written just for this project.
It would, however,  be at the cost of complexity of your code,
divergence from a standard implementation and loss of the support of
the community of Moose users.  I advise you not to fall into the trap
of re-implementing something that is already done elegantly and tested
by hoards of users.  We do this at work all the time to the tune of...
well... far too much time, energy, and money.

http://en.wikipedia.org/wiki/Not_Invented_Here#In_the_free_software_community

> > =head2 logpath
> >
> >  Attribute which indicates the log directory.  Defaults to /var/log/xen-tools
> >
> > =cut
> >
> > has 'logpath'  => ( is      => 'ro',
> >                                isa     => 'Str',
> >                                default => '/var/log/xen-tools'
> >                                );
> >
> > EOF
>
>   That just seems alien to the way I think about and read perl.  It's
>  too much like magic, and not enough like simple to modify and extend
>  for me.

I see where you're coming from.  It took me a while to become
comfortable with it as well.  But if you read it a few times, you'll
see that it is syntactic sugar around a common mechanism.  Consider
this instead:

my %logpathDef =
  (
     is         => 'ro',
     isa       => 'Str',
     default => '/var/log/xen-tools',
  );

has( 'logpath', %logpathDef );

> > Okay.  I'll review and provide a patch so you can see whether the
> > convenience, simplicity and maintainability outweigh the cost of
> > having another external dependency.
>
>   I'm 60/40 against at the moment to be honest.  But at the same
>  time I don't want you to stop sending code..

Heh.  There's the rub, eh?  Maybe it would help if I gathered a list
of interesting projects using Moose and asked the authors to give a
list of reasons they decided to use it?

> Steve

-- 
moo.