some try-ark suggestions
<[email protected]> Sat, 9 Jun 2001 12:02:01 -0500 (CDT)
| Newsgroups | gmane.comp.sysutils.ark.devel |
|---|---|
| Message-ID | <[email protected]> |
Will:
As you know, my second go at Arusha failed with
import xml.dom.core
ImportError: No module named core
As I see it, there are at least three possibilities for this error:
--There is some missing piece outside of $ARK_SRC. If so, identify it
(and other missing pieces), and add to the "Getting/installing the
prerequisite tools" section as necessary.
--There is a mistake (quite possible) in my rudimentary myteam1 setup
and configuration. This is my problem and/or your problem, in that your
instructions are unclear or incomplete, I missed or botched something,
or some combination of goofs on both our parts.
--There is some missing piece (or pieces) in the CVS checkout that you,
with your complete, functioning setup (not to mention your full
understanding of Arusha) take for granted.
If the third explanation applies here, I have some suggestions.
If the problem lies with the cutting-edge CVS archive and not the FTP-able
snapshots, I would change this statement
It may be simpler, however, to use a single set of FTP-able snapshots,
e.g. ark-20010306-*.tar.gz.
to this
The CVS archive is cutting-edge, and you may encounter difficulties
using it. It is really intended for experienced Arusha users and/or
developers only. We strongly advise you to FTP down the most recent
snapshot when first trying Arusha.
OR, I suggest that you put together a conventional distribution tarball,
e.g., ark-20010306_try-ark.tar.gz, which is a complete, guaranteed-to-work
(assuming the correct per-site xml config file tweaks) $ARK_SRC.
(The "20010306" in "ark-20010306_try-ark.tar.gz" suggests functionality on
a par with Arusha as of 2001/03/06. In the meantime, you may have gone
on to releasing later-dated versions.)
So, the beginner should be able to download this conventional tarball,
unpack it, inspect a README file replicating or distilling the essential
steps, and go right to a guaranteed-successful try-ark run.
The important point here is that you need to provide the new user a sure-fire,
"feel-good", first-time success, inspiring him/her to proceed and not just
throw up his/her hands in despair.
Don't be tempted to rush the new user into trying the latest and greatest
Very Cool Stuff right away at the risk of possible frustration and failure.
I know that you have written something like "Arusha is a framework and not
a conventional unpack-and-run sort of tool." Still, for the initial
try-ark baby step, I suggest you consider making something unpack-and-run.
One problem is that, once you have this guaranteed-to-work try-ark tarball,
how do you keep it up to date with ongoing Arusha (and sidai and ...)
developments? Response: Is it really so bad if the try-ark tarball gets
a bit out of date? Maybe commit to updating the try-ark tarball on a
quarterly basis, or each time some major new Arusha version gets released.
Or maybe some automated tool (or religiously followed procedure you follow)
to keep the try-ark tarball in sync with the latest and greatest Arusha
developments.
Does any of this make sense?
Berto
-------------------------------------------------------------------------------
Robert Osterlund, Unix Systems Manager [email protected]
Grad School of Business, U of Chicago phone: 773/702-8898
1101 E. 58th Street, #309, Chicago, IL 60637, USA fax: 773/702-0233