On Wed, 7 Mar 2001, Lee Burgess wrote:
> > > I mean, seriously, are there *any* systems out there that don't come
> > > with perl pre-installed these days? Or, are there any site
> > > integrators out there that don't use perl in *some* respect to do
> > > their jobs (thereby guaranteeing that perl is available)?
> >
> > Many systems come with Perl, many do not. The problem shows
> > up when you depend on having that piece of software
> > installed before yours will work. This is even more
> > critical when it comes to your tests cases. Suppose
> > you run the test cases and they all fail. What is
> > at fault? Is the version of Perl (or whatever,
> > I am not attacking Perl here) installed on the system
> > broken? Is Perl installed at all? Is it a different
> > version than your test cases expected? Is it your code?
>
> Don't look now, but you just provided an argument against using Tcl.
> Just s/Perl/Tcl/g in the above paragraph. :)
ANY external dep is an issue, that was kind of the point :)
> > I don't think they are edge cases. If you want to
> > depend on Perl then it should be included in the
> > source tree. If folks have that exact same
> > version installed on the system, they can
> > pass --with-perl=PATH to use it. Otherwise, a
> > known version should be built from the source
> > tree. You don't have to install it, but you
> > should use it to run the test cases.
>
> I think this itself is a bit extreme. If we should decide to write
> the test suite in Bash, does that mean we need to include Bash in the
> source tree? Is Bash standard enough that we don't have to worry
> about version compatibility? Rhetorically speaking, the same could be
> asked of Python or Tcl (Jacks). I mean, I know for a fact that the
> Perl and Python developers go to a lot of trouble to insure backward
> compatibility. I cannot speak for Tcl, but I would assume the same.
This has nothing to do with your scripting language of choice.
It has everything to do with bootstrapping a tool's build
process. If I try to install subversion of a fresh Solaris
box, you can be sure there ain't gonna be a recent version
of Perl, Python, Tcl, Berkeley DB, or whatever on it.
I know it "works for you" on a Linux box with all
the most recent updates. That is not the point.
This is why autoconf is written in brain dead sh. It
does not use bash features because bash can not be
depended on to exist everywhere. Yes, it does exist
on *most* machines but not all. You don't want to
be the poor sap who finds this out when trying
to build on system X. Same goes for automake,
yes it is written in Perl but it does not
require Perl at build time, it is only required
on the developers machine. Am I saying a
test suite should be written in sh? No,
clearly not. But if we are going to depend
on something, the toplevel configure
should take care of it.
For a fun example of what I mean, go grab openssh
and try to build it on a system that does not have
perl installed. I tried to enlighten folks
on the openssh list. I even wrote a sed script
to replace the one perl script they were using,
but they just did not seem to "get it". Now
ask yourself, should I really need to build
Perl before I can build openssh?
> So really, no matter what interpreted language is used (if any), it
> should be written in a safe and generic way such that the version does
> Maybe I am missing something, but saying that we should include Perl
> (Python or Tcl) in our source tree is overkill, mainly because it is a
> common tool. It's like saying we should include an ANSI C compiler in
> the Subversion source.
Sure, as soon as you can explain how we are going to compile it :)
> If we are talking about Joe Developer writing tests, then it might be
> helpful to consider how pervasive each tool is in the community. I
> think "ease of use" certainly correlates to "familiarity with" in this
> case. That is, I am willing to bet that developers' familiarity with
> the three mentioned languages rates like so (greater familiarity to
> lesser):
I am not sure how a popularity contest is going to help.
I agree with your comment about assessing the
acceptability of a tool for a given task,
but I think it is unrelated to the the
dependence problem. The assessing
task is going to require some real
metrics, which is always the sticky part.
If folks want to use Python to drive the test
suite, that is fine with me. Just make sure
all the tools the subversion test suite
depends on get built when ./configure is
run and I will be happy. Of course,
people should be able to override
using --with-perl or --with-berkeley-db
or whatever.
Mo DeJong
Red Hat Inc
Received on Sat Oct 21 14:36:25 2006