[kepler-dev] [Bug 5458] Moving between 2.2 and 2.3 and back requires deleting ~/KeplerData

[bugzilla-daemon at ecoinformatics.org]

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=5458

--- Comment #6 from Derik Barseghian <barseghian at nceas.ucsb.edu> 2011-08-25 18:13:28 PDT ---
As of 2.2, when using the module manager modules are downloaded into
KeplerData/kepler.modules, and the build system starts kepler as a combination
of modules in this folder(if they are present) and those in the Kepler app
folder. When you switch to a suite, if the suite needs a module the app folder
already has, it is not downloaded into KeplerData/kepler.modules. I didn't
realize this is how it worked; I thought all modules utilized on a given kepler
startup were all in one place or the other. There are parts of the build system
that behave as if all modules can be found in one place or the other, as I'll
mention at the bottom of this post. David, is starting up using a combination
of modules in the app and the kepler.modules folder by design, or accident?

There's a file called use.keplerdata that when present (and it's always
included in the installers from 2.2 on), makes kepler download to
KeplerData/kepler.modules/ instead of the app folder. There's a file in the
application's build-area folder called install-id.txt that contains a value
like 2.2 or 2.3. When the value in this file is different from the copy in
KeplerData/kepler.modules/build-area/, the files from the kepler application
build-area are copied into KeplerData/kepler.modules/build-area, unless they
already exist there.

If use.keplerdata is present, the files kept in
KeplerData/kepler.modules/build-area (like modules.txt, current-suite.txt, etc)
are used for startup instead of those in the app build-area, e.g. to determine
what suite to start. 

The current problem is that this system won't work when you have two kepler
apps that both have a use.keplerdata file.

Kepler-2.3 will fail to start if
KeplerData/kepler.modules/build-area/current-suite.txt (and/or modules.txt,
i've never been clear on the different usages of these two) are set for
kepler-2.2.0. All of the modules needed by the kepler-2.2.0 suite would have to
be included in the combination of the modules in the kepler 2.3 app and
KeplerData/kepler.modules/ for this to work.

Similarly kepler-2.2 will fail to start if
KeplerData/kepler.modules/build-area/current-suite.txt (and/or modules.txt) are
set for kepler-2.3.0. 

I don't think keeping separate KeplerData/kepler.modules/build-area/2.x folders
is a solution. I tried this and failed. It also complicates things even
further. You can use the 2.3 app to change-to 2.2.0. The
KeplerData/kepler-modules/build-area/2.3/ files become set to 2.2. On
auto-restart, the 2.3 app build-area files will be copied into the
KeplerData/kepler.modules/build-area (the 2.2 location). The MM then shows that
you're in 2.3, but the splash screen shows you're in 2.2. I'm not sure what
you're in. On a subsequent attempt to start the 2.3 app, startup fails with a
missing module message. A number of other problems also cropped up.

1) One way to not delay the 2.3.0 release too much longer is to not include
use.keplerdata. This would mean dropping support for users being able to
download add-on modules when they don't have write support to the application
area. I think this how most applications work. Do we have users that this would
be a problem for?
2) Another way is to not put out a 2.3 installer, and delay fixing the build
system. Instead users would upgrade to 2.3 via MM.

With option 2 there's at least one problem that itself isn't huge, but points
to a larger issue.
* Possible problem: If you use 2.2 to move to 2.3, you don't get the latest
build-area. I don't know if this will cause problems, probably not.
* Problem: In 2.3 on mac, the file menu items are back on each individual
kepler window (not mac style). 2.2 and 2.3 both use apple-extensions-2.1.0. The
problem is fixed if you copy this module into KeplerData/kepler.modules/,
implying something is looking for this module in the wrong place. I tracked
this down, the issue is that kepler.Kepler.main just looks in
KeplerData/kepler.modules/ for osextension.txt files. This is because
ProjectLocator.findKeplerModulesDir() determines that the projectLocation is
KeplerData/kepler.modules/, even though it's actually a combination of the app
folder and kepler.modules. Is there even a way to know which instances (on
disk) of Modules are in use? I'm not seeing one. Module.getDir() can return the
wrong value. There are many directory variables that are set to
nonexistent-on-disk paths, and I wouldn't be surprised if there are problems
lurking because of this.

-- 
Configure bugmail: http://bugzilla.ecoinformatics.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.