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

On Fri, Nov 20, 2009 at 2:36 AM, Eli Barzilay <eli at barzilay.org> wrote:
> On Nov 17, Carl Eastlund wrote:
>> On Wed, Nov 4, 2009 at 4:44 PM, Carl Eastlund <cce at ccs.neu.edu> wrote:
>> > That's a bunch of issues, and three proposals: (1) set up PLTUSERDIR
>> > to control placement of Planet and Scribble generated files, (2) pick
>> > a conventional place in the PLT tree for users to store it who can and
>> > wish to do so, and (3) longer term, think about a way to fit
>> > development link code into this story.  So -- what do the rest of you
>> > developer folks think?
>>
>> I did #1 and #2 on a branch
>> (http://svn.plt-scheme.org/plt/branches/cce/plt+addon-dir).  I
>> updated the C implementation of (find-system-path 'addon-dir) to
>> first check the PLTADDONDIR environment variable; Planet and
>> Scribble both use the addon-dir, so it seems to be the right point
>> of control.  I also updated the Scribble documentation for
>> find-system-path, and added an svn:ignore property for
>> $PLTHOME/add-on as a canonical place for in-tree add-on directories.
>
> I see several issues with this:
>
> 1. As much as I personally like environment variables, it seems that
>   they're generally confusing.  Doing this change as another variable
>   means that now the exact collection search is determined by:
>   - $PLTCOLLECTS
>   - Uses of `-S', `-X', and `-U'
>   - $PLTADDONDIR
>   - Any dynamic changes to the search path
>   The first is a good source of complaints and confusion, and adding
>   another environment variable seems like it will make things worse.
>   (It doesn't help that Windows and even OSX users find it difficult
>   to control them.)

You forgot $PLTPLANETDIR.

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.

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

> 2. There is a potential problem with code that uses `find-system-path'
>   with 'addon-dir where 'pref-dir should have been used.  But at
>   least on my system I don't see anything that would break.

That sounds like a complaint about find-system-path, regardless of
this environment variable.

> 3. IIUC, the only problem that this solves is using several different
>   installations with the same version number, is this true?  Is that
>   problem *so* common?  If so, then maybe have instead a way to use
>   your own additional suffix to the version part that gets used in
>   ~/.plt-scheme/<here>/ and ~/.plt-scheme/planet/300/<here>/ ?

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) unable to run any PLT Scheme code of any
variety -- essentially unable to work -- or I need some way to have
two PLT Scheme installations of the same version that don't "share"
compiled planet code.

>   Or maybe go the other way -- make the default addon-dir include the
>   version (so on linux it becomes ~/.plt-scheme/<version>), and have
>   no version directory for the local collects (so they end up in
>   exactly the same place), planet can drop the version directory too
>   (and the redundantly outdated "300" part).  Then it makes more
>   sense to have a command line flag or environment variable move
>   everything, without getting a second level of version-dependant
>   directories.  (The only problem that I see here is that the planet
>   "cache" is less of a cache than it is now.)

Maybe we need two settings -- PLTADDONIR and PLTVERSION.  The
PLTADDONDIR would then be static (I'd have no need to set it more than
once -- and if I don't mind the default, not at all), and have a
subdirectory for each version, plus one for a shared planet cache.
Then I could set PLTVERSION for separate installations, which would
override the version string *only* for the purposes of choosing a
subdirectory of PLTADDONDIR.  The directory tree would look like this:

$PLTADDONDIR/
  planet-cache/
  4.2.2/
    collects/
    planet/
    scribblings/
  4.2.2.1/
    collects/
    planet/
    scribblings/
  ...and so forth...

This would be a significant change to the way things are layed out,
though.  My current patch doesn't break any existing setup or change
any existing directory structure.  Furthermore it is already written.

--Carl