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

From: Eli Barzilay (eli at barzilay.org)
Date: Sat Nov 21 14:05:59 EST 2009

On Nov 21, Matthew Flatt wrote:
> At Fri, 20 Nov 2009 15:51:19 -0500, Eli Barzilay wrote:
> > Look, the story with environment variables vs command-line flags
> > is esentially the same one as with keyword arguments vs
> > parameters.
> 
> I completely agree. But how does this lead you to the conclusion
> that environment variables are bad?

There's no conclusion that they're automatically bad -- just that they
should be avoided if possible.  The problem with `plt-help' is an
indication that an environment variable would be more convenient than
to find a way to thread command-line flags through applications.
Given this, having both a command-line flag and an environment
variable is a good solution, and the fact that if both are specified
then the flag should override the variable is a good indication that
the variable lookup should happen once on startup rather than every
time.  BTW, the problem that I said already exists is not with `-X'
and `-S', it's `-U' which is a problem in that plt-help doesn't accept
it.

But there's another potential problem: the addon-dir is used for code,
which means that the two settings are dependent, so it would have been
nice if there was a way to do them both in PLTCOLLECTS.

Also, speaking about using environment variables -- how about another
for the preference, and respecting HOME when set on Windows possible
with some `expand-user-path*' that will work on Windows too?  The
latter two are especially annoying for writing cross-platform scripts,
where I often need to edit code to use (getenv "HOME") for it to work
on my (windows) laptop.


> > 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.
> 
> The same with parameters, but we'd have a hard time getting by
> without them.

They're not the same -- parameters are in the scheme world, so they're
uniform like all other code.  But environment variables are set in
very different ways and in different places.  For example, at some
point the debian distribution arranged for PLTCOLLECTS to be set in
the default user environment (at least IIRC), on windows you have
several ways to change them, and finally trying to control environment
variables in deployed applications is very easy on unix/osx, and very
difficult on Windows (which is what lead to the need for `path-up').

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!


Posted on the dev mailing list.