[plt-dev] Re: Generated files and co-existing copies of DrScheme

From: Carl Eastlund (cce at ccs.neu.edu)
Date: Fri Nov 20 16:42:28 EST 2009

On Fri, Nov 20, 2009 at 4:32 PM, Eli Barzilay <eli at barzilay.org> wrote:
> On Nov 20, Carl Eastlund wrote:
>> Re: command line argument vs environment variable:
>> You are right, it works either way.  Since we already have
>> environment variables to control this kind of thing, I went with
>> another environment variable.  I don't think having two things
>> controlled via enviroment and one via command line is going to be
>> somehow less confusing than having three environment variables.  If,
>> some day, we overhaul this configuration system, I have no problem
>> with going to all command line arguments (or just one switch, as a
>> command line argument).
> The general good direction, IMO, is to avoid environment variables as
> much as possible.  So if you want to add a new knob, doing that with a
> command line argument has better chances of being useful and of
> staying around.  Do you have any *concrete* point for preferring an
> environment variable over a command-line argument?

I am preferring consistency over inconsistency.  Betamax was better
than VHS, but once 90% of the world was VHS there was no sense in
making Betamax any more.  People are using our VHS options already, so
why not give them more VHS, even if Betamax is better?

That *was* my argument.  I think my point that "users only have to use
the old way or the new way, not both" undermines it.  If users use
*either* the PLTPLANETDIR environment variable *or* a command line
option for add-on directories, it becomes easier to justify the

However, since I am using the same kind of script as you for calling
PLT executables -- the command line approach is only easy to use if we
make sure every PLT executable can accept the same argument.  Do we
have a single point of control for that?  Or will we have to edit
several programs to make sure they accept this new option?

>> First, do we want to redesign our local configuration system,
>> addressing issues of how directory trees are laid out, what options
>> users have, and how users express choices.  This will take careful
>> design, time to implement, and a decision of how to deal with the
>> fact that it will almost certainly break existing configurations.
> This was mostly done, with the new command line arguments and with
> changes that happened in the past.  PLTCOLLECTS might be more
> difficult to pull out, but I won't cry when this is done.

What new command line arguments do we have for this?  The only ones I
see are for collections; I don't see any for planet, scribble, or
preferences -- any of the Mz/DrScheme generated files.

>> Re: nightly build:
>> This doesn't solve my problem, because nightly builds do not include
>> planet packages,
> Of course, but I talked about building the PLT tree itself, which is a
> conserable chunk of work that you don't need to do.

But that's the part that also doesn't clobber anything, and thus isn't
a problem for me.

>> and a new nightly build will still clobber the local planet and
>> scribble files of an older one with the same version.
> How?

How else would it work?  Where will it put these things, other than
right where the previous build did?


Posted on the dev mailing list.