On Fri, 6 Jun 2003, Mark Taylor wrote:
> > Clearly in the longer term we need to resolve the issue of how to control
> > package access. Personally, as I've said from time to time, I think we
> > should seriously consider breaking with C-shell aliases as our primary way
> > of defining commands, using a PATH system would be more natural and shell
> > neutral.
>
> I agree. As I've said earlier, I'm inclined to favour a single bin
> directory, unless there is some reason this would be impractical,
> e.g. many executables with potential/likely namespace clashes;
> I don't forsee this being the case in the near future.
>
> For non-unix OSs (in which we won't be supplying startup scripts, so
> package startup will have to be done by invoking jar files direct) it
> would probably make life easier for the same reasons to have the
> package jar files all in a single lib directory rather than in
> lib/package/package.jar. There are namespace/3rd party versioning
> issues here, but I can think of ways round.
The problem, as I see it, is namespace pollution. We may have a smallish
set of commands per package at present, but it's only going to grow, I
remember when KAPPA had about 10 commands (got the SUN around somewhere),
and there were a few packages, look at it all now. Any choice we make must
be at least scalable in principle. Keeping things in separate directories
per package is almost guaranteed to be manageable, just not as convenient.
One thought I've toyed with is just to have the "entry points" in the lib
and bin directories, so our main jar files lives in "lib" and resolve into
sub-directories for extra and third party stuff, which is OK, but for
commands you'd then start writing things like:
% kappa cadd in=xxx const=10 out=xxx
% kappa cmult in=xxx ....
not so nice.
Peter.
|