[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 #7 from Derik Barseghian <barseghian at nceas.ucsb.edu> 2011-09-08 16:15:25 PDT ---
I've fixed the issue with sometimes being unable to find osextension.txt files
and thus sometimes not loading os extensions at r28458. I plan to patch 2.2 to
include this fix.

(In reply to comment #6)
> 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.