Jonathan Cunningham <jlc@sofluc.co.uk> commented on some remarks by
Steve Leach and by me.
I don't disagree with anything Jonathan wrote, though probably because I
did not explain clearly what I was getting at, he mistook my intent in
my paragraph on multiple versions.
Jonathan wrote:
> Date: Wed, 22 Mar 2000 23:17:19 -0000
>
> Steve Leach (Hi, Steve) says about environment variables:
>
> >Actually, I understand that there is a good reason. Apparently it
> >helps the Poplog devteam work with multiple versions. However,
>
> I was resisting the urge to followup on this, but since I'm replying
> to Aaron (below), I'll make the same point here. I would prefer to
> say, not that "there is a good reason" but that "there was a good
> reason".
I'll go along with that, and in my message pointed out that for most of
those "good" reasons the sort of alternative suggested previously by
Andrew Sayer would work (i.e. setting up popenvlist, or various other
lists, after poplog starts up, in the basis of some sort of central
or user initialisation file).
However, different reasons need different treatment.
> Actually, with 20-20 hindsight (and inspired by the recent discussion
> on this group), I think it is more accurate to say that the zillion
> environment variables are one solution to a problem,
To be more precise, Poplog uses different environment variables as
solutions to different problems, some more important than others.
> ...
> Internally, pop11 may need to distinguish skillions and whillions of
> directories and search paths. The problem is simply to initialise some
> internal data structure (or set of variables) with this information.
>
> There is no reason why, when poplog starts up, it cannot read this from
> a configuration file.
I think we have all now accepted that point regarding most of the
environment variables.
However, some of the environment variables are used to determine which
version of poplog to run. One is $usepop, and the other is the standard
Unix environment variable $PATH. I used to think both needed to be set
up before one gave any command to run poplog, but I now suspect not.
I'll comment on $PATH below, and on $usepop in another message.
There's another group of variables used to determine not which version
of poplog, but which language system or saved image you want to run,
e.g. basepop11, pop11, prolog, clisp, pml, etc.
I'll elaborate on some options for that in a later message.
> The programming language "pop11" is quite
> powerful enough for this purpose, and so the configuration file could
> be written in pop11 (although I would probably design something
> language-neutral).
Yes. We don't need the extra syntax that pop11 would require. E.g.
lines of name value pairs separated by space or '=' would suffice.
(Compare the difference between vedsetkey, which is a procedure and
requires pop11 syntax, and vedset, which is a syntax form defining a
language-neutral way of specifying ved's key bindings, screen behaviour,
etc.)
We need something similar for pop-11's and Xved's defaults, instead of
the horrible (in my view) requirement to set things in an external
general purpose X defaults file, the point of which I've never
understood.
> I don't think I'm saying anything that wasn't implicit in what both
> Andrew and Steve have already said.
And I had agreed also!
> ...
> Now I'll reply to Aaron's comments:
>
> >1. Poplog, unlike linux default mechanisms, was always designed so that
> >one can have more than one version installed simultaneously. So a new
>
>
> Indeed. And environment variables were one way to achieve this.
When I made that point it was not intended to be a comment on the
environment variables that are unique to poplog, but a comment on the
notion of 'the linux way' of doing things, a notion which I think Andrew
had brought up.
And as I understand it the linux way of doing things (unlike Solaris,
for instance???) is that for a complex new package all executables go in
the same bin directory (e.g. /usr/local/bin/, all stuff to do with
libraries go in the same lib directory e.g. /usr/local/lib/ or maybe
/usr/X11/lib, all man files in /usr/local/man, etc.
So that means that when you install a package you scatter files all over
the place, and that makes it hard to have simultaneously a new and an
old version of the package given that all the files have the same names
in both.
I was contrasting that way of installing a package with keeping
everything relating to the package in ONE directory tree and altering
the standard "path" variables, e.g. $PATH, $MANPATH etc.
That not only allows different versions to coexist but also simplifies
addition and deletion. You don't need to keep a table of things to
remove when you remove a package: you simply delete the directory tree.
If a new version becomes the current one, then a single file "sourced"
by all users on the system, can be edited to specify the root of the new
tree.
So the poplog way of doing things, keeping everything in one tree,
requires a few existing Unix environment variables to be changed.
I believe that that's far better for most users. Steve, whose concerns
are different, e.g. use of pop11 in system startup scripts, disagrees,
and thinks that in order to be used as a system language it will have to
do what the others do, e.g. perl, gcc, or whatever.
HOW TO DO IT
Assuming you have different versions of poplog (e.g. an old one, and
a new one that's on trial for a while, for use by experts) in different
directory trees there is the problem of how users gain access to the one
they want. Let's assume for now that the problem of setting appropriate
values for $usepop $popexternlib, etc. etc. can be solved once poplog
starts up: how do you start up the one you want?
Method 1
Obviously one way is to extend $PATH to include the directory containing
poplog executables, which is what happens now, in
$usepop/pop/com/poplog
$usepop/pop/com/poplog.sh
(Incidentally the directory is called 'com' not 'bin' because poplog
started life on a Vax running VMS, having previously been a very much
simpler pop11 executable on a tiny PDP-11/40 computer running Unix.)
Method 2
If you don't want to have to change $PATH, to specify the version of
poplog you want, another way is to put symbolic links with different
names in the bin directory, for instance. Thus /usr/local/bin/pop11
could be a symbolic link to the old version of pop/pop/basepop11, and
/usr/local/bin/pop11.new (or something else) could be a symbolic link to
the new version).
And likewise clisp, clisp.new, pml, pml.new etc. This could work, and is
only a little messy. If the "man" files change with different versions,
it starts getting too messy.
That has the advantage over the use of environment variables and $PATH
that you can quickly and easily switch between running pop11.new and
pop11, whereas now you have the nasty task of unsetting environment
variables, then re-setting them (for which I have a shell script copied
from sussex, if anyone wants it!).
I.e. in this approach, instead of scattering around a lot of files, you
scatter symbolic links (and make sure that initialisation files within
the different versions do the rest).
Then deleting an old version means simply deleting ONE directory tree,
though you may have some dangling symbolic links if you don't put
something else in its place.
Installing a new version which does not replace an old version, then
requires installing or changing some symbolic links to point to the new
version.
However, if you have to keep track of too many symbolic links to
change/remove, it can be almost as bad as scattering the files. (I've
not tried to work out how many would be needed: probably fewer than 10).
Method 3
There is another obvious way to do it, which I had not previously
considered, which avoids having links with different names for old and
new versions. That is to have a system-wide standard directory for new
versions of packages, e.g. /usr/local/newbin/ which is by default on the
$PATH of everyone interested in *new* versions. Then the pop11,
basepop11, clisp etc. in that directory are all symbolic links to the
corresponding files in the new version of poplog, and the new versions
will simply shadow the links in /usr/local/bin to the "current" version.
But that solution requires users to buy into all the "new" versions of
all packages, which some will relish and others will not.
Another variant of that would be to have different classes of "newbin"
directories, and then one could select which ones to put on one's $PATH.
I don't know how many Unix "path" environment variables would need to be
handled this way (MANPATH, LD_LIBRARY_PATH, ???). But doing that may be
not much better than just putting onto $PATH additional directories
of executables.
Method 4.
Yet another solution is a variant of the poplog shell script previously
announced, which can go into a standard bin directory and which sets
environment variables or uses some other mechanism to select the version
wanted.
Then a script called newpoplog could be run as
newpoplog pop11
newpoplog clisp
newpoplog xved
etc.
This, like the symbolic links with different names in Method 2, makes it
very easy to switch between new and old versions.
But several people have already objected to starting up Poplog via
shell scripts.
There are probably other solutions people will think up.
And there may be people who are sure they will never want to have two or
more versions installed on their machines and simply don't want to have
to put up with mechanisms whick support that option.
(Just wait till Poplog V16 is released, with all the changes now being
discussed!!).
[AS]
> >version could be installed on a system for testing by experts and brave
> >people while the old version remains available for the rest. Later the
>
[JCL]
> And a configuration file would let you do the same thing, without
> knowing what an environment variable was.
The point I was making at that stage was not that we need environment
variables for different versions, but that we need different versions,
and it is hard support that doing things 'the linux way', i.e.
scattering files in various standard directories. Sorry to have confused
the issue.
If you run everything via a shell script which invokes the version of
basepop11 that you want, then use of initialisation files will
work for everything else.
(Doing that would require only a tiny change to the existing shell
script that makes it unnecessary for people to pre-set environment
variables before invoking poplog.)
I thought part of the context (raised by Andrew and Steve) was wanting
to avoid shell scripts. My next message will propose an alternative,
based on using sysexecute to start a different version.
[AS]
> >2. I don't know all the reasons why poplog has so many environment
> >variables, but one reason they can be useful is if a common file server
>
[JLC]
> Perhaps because it seemed like a good idea when there were only two
> or three? And the number just grew and grew??
>
> (snip)
Maybe. I don't remember being involved in the detailed discussions of
the environment variables. E.g. I was very surprised to find
$poplocalauto for instance, given that $poplocal exists.
> The rest of Aaron's comments seem to me to be explaining, justifying
> and defending the current mechanism, with suggestions for how it can be
> improved.
I think it is important for people thinking about this issue to
understand the different reasons why the environment variables are
there. Then different solutions may be best for different classes of
reasons (and variables).
So far most of the discussion has focused only on a subset of the
environment variables, the ones related to search paths and directories
of executables and libraries. My next message will address some other
issues.
> In the interest of clarity, let me be explicit: it seems to me that
> the drift of the discussion was not that the environment variable
> mechanism needs to be improved, but that it could be replaced by a
> purely poplog mechanism, and that this might have advantages.
>
> To run poplog, even when there are multiple overlapping installations,
> and many different users, you need two pieces of information:
> (1) Which executable binary file to run (newpop, pop11 or whatever)
> (2) Where your individual configuration information can be found.
and also
(3) which saved image to start up, e.g. clisp, prolog, pml, bare
pop11, or some other. At present this is linked to the *name* by which
you invoke the very same binary.
> If you were designing a solution to this from scratch, it is unlikely
> you would invent the current mechanism. So if you wish to defend the
> current mechanism, you have to be able to justify why a more elegant
> solution cannot be used. "The current mechanism works" is not
> sufficient justification to rule out discussion of alternatives.
I don't think anyone was saying that.
Apologies if that's how my message read.
Cheers.
Aaron
===
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs/ )
School of Computer Science, The University of Birmingham, B15 2TT, UK
EMAIL A.Sloman AT cs.bham.ac.uk (ReadATas@please.com !)
PAPERS: http://www.cs.bham.ac.uk/research/cogaff/
TOOLS: http://www.cs.bham.ac.uk/research/poplog/freepoplog.html
|