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

On Fri, Nov 20, 2009 at 3:51 PM, Eli Barzilay <eli at barzilay.org> wrote:
> On Nov 20, Carl Eastlund wrote:
>>
>> I would be happy to try to simplify this to a single environment
>> variable, but I think that means adding PLTADDONDIR and letting it
>> replace PLTCOLLECTS and PLTPLANETDIR (not to mention the purely
>> hypothetical PLTSCRIBBLEDIR).  I'm not sure whether breaking
>> compatibility for anyone who uses PLTCOLLECTS or PLTPLANETDIR is
>> worth it for the amount of simplification.
>
> I don't think that it's possible to make a single variable as powerful
> as all three.  In any case, and as is usually the case with
> environment variables, changing things is very painful, since these
> things are stuck in all kinds of places.
>
>
>> >   So, I think that a command-line argument would be better.  It
>> >   might even make sense to use `+U'.
>>
>> Then I have to type it every time I run the command, though.
>
> Why?  If you know how to use them, then you should be able to use a
> script.
>
>
>> I want something I can, for the most part, set and forget.  And I
>> need the command that runs 'mzscheme' to be 'mzscheme', for instance
>> (not 'mzscheme-4.2.2') so that scripts that call 'mzscheme' always
>> get the one that I have chosen as recently built and fully
>> functional.
>
> I don't get this.  Translating an environment variable into a
> command-line argument is trivial.  In this case, if there is a `+U'
> and no environment variable, I can still get it with:
>
>  #!/bin/sh
>  if [ "x$PLTADDONDIR" = "" ]; then exec /path/to/plt/bin/mzscheme "$@"
>  else exec /path/to/plt/bin/mzscheme +S "$PLTADDONDIR" "$@"
>  fi
>
> Or, since you want the addons to be in the PLT tree, then here's a
> version that uses a PLTHOME variable:
>
>  #!/bin/sh
>  exec "$PLTHOME/plt/bin/mzscheme" +S "$PLTHOME/addons" "$@"
>
> Now you just need to set PLTHOME and get everything -- and you don't
> even need to specify the path to the right mzscheme to run.  You can
> even call it `mz', making it even easier to start.
>
> [FWIW, this is exactly how I run mzscheme -- I have a script that
> chooses a binary based on PLTHOME, and I have a convenient shell alias
> to toggle between the released version and the nightly build, and in
> the case of the released version in my home directory I have this
> script choose the right binary because I'm using a single directory
> with binaries for all platforms.]
>
> Look, the story with environment variables vs command-line flags is
> esentially the same one as with keyword arguments vs parameters.
> Parameters are more convenient in ways that make them lead to
> potentially more mess, like forgetting that the code goes through some
> dynamic context that changes it.  In your patch for example, you fetch
> the environment variable dynamically, which means that things can get
> interesting with code that uses `putenv'.  Fixing that wouldn't be
> hard, and it would get a bit closer to just a command-line flag.
>
> Another problem with environment variables is that they get passed on
> in strange ways.  I've seen people hopelessly confused on Windows,
> since changing the environment is done in an awkward way.  I've also
> seen cases where people had scripts that would set the variable
> somewhere on the way, in a place that they didn't see, leading to very
> confusing bugs where things are just not right no matter what you do.
> It's like the usual problem with parameters being dynamic, with the
> added fun bit of doing so cross-language (from shells to the process),
> and/or weird places where you get to set your environment variables.
>
> This is why I'm saying that personally I like them -- I work in a way
> that makes them very obvious (a traditional shell, basically).  But
> that's not true for probably somewhere around 95% of the users.  (You
> can see that in one of the many emails about PLTCOLLECTS -- it uses
> the colon convention which just makes a lot of sense, and is used in
> several places -- so I thought it would be much more known than it
> turns out to be (=> roughly zero people knew about it).)
>
>
>> I run into this problem every single day when I update my PLT trunk
>> checkout.  I either have to spend the duration of a complete build
>> (including all documentation, installed planet packages, and recovery
>> from any build errors)
>
> That goes back to the nightly build -- why not use it?  It *is*
> happenning every day, and the results are packaged in about 200
> different ways.  (Yes, you still need planet, in case the version or
> some interface changed, but most of the work is done if you use the
> nightly build.)
>
>> unable to run any PLT Scheme code of any variety -- essentially
>> unable to work -- [...]
>
> Or the least you can do if you really don't want to use the nightly
> build is run it during the night in a cron job.
>
>
> On Nov 20, Carl Eastlund wrote:
>> On Fri, Nov 20, 2009 at 9:05 AM, Robby Findler
>> <robby at eecs.northwestern.edu> wrote:
>> >
>> > Not to be contrarian, but pre-relase docs are probably close enough
>> > usually, right?
>>
>> Unfortunately, the new docs invariably lack planet packages (both
>> downloaded and development linked).  I spend a lot of time
>> programming with planet code, and looking up documentation for it,
>> and without up-to-date local documentation I wind up having to go to
>> planet.plt-scheme.org and lookup documentation by browsing specific
>> versions of each package, without the benefit of Help Desk's search
>> page.
>
> But that should be a much faster process to compile just these if you
> use the nightly build.  Or in almost all cases you should be fine with
> the same build when the PLT version didn't change.

Re: making a single variable as powerful as all three: the PLTADDONDIR
I have already implemented already covers scribble and planet.  You're
probably right that it won't cover collects, but those aren't
"add-ons" in the sense of files PLT Scheme installs automatically.  It
could probably cover the preferences file, but I'm not 100% sure
that's either possible or desirable.

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).

I agree that proliferating the number of controls (collects, planet,
add-ons, scribble, partridges in pear trees) is not something we want
to do ad nauseum.  I also agree that environment variables are not
always the best way to control things.  I see two separate issues
here.

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.

Second, since such a redesign will not happen soon and may not happen
ever, what do we do for now?  I am not proposing that PLTADDONDIR is
anything other than a workaround patch.  I think it is, however, a
good workaround patch.  It is already implemented, it does not break
existing configurations, and as far as I can think of, no one should
have to use both PLTADDONDIR and PLTPLANETDIR.

Re: nightly build:

This doesn't solve my problem, because nightly builds do not include
planet packages, and a new nightly build will still clobber the local
planet and scribble files of an older one with the same version.
Furthermore, as a PLT developer, I want to have svn access to the
trunk -- I do occasionally update or commit a checked out tree, rather
than merely checkout / build / delete.

--Carl