You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Installing a fresh clone to a new location (after having run galaxy from a different location) and running via run.sh will reuse the value of GRAVITY_STATE_DIR from previous installation.
Galaxy Version and/or server at which you observed the bug
Galaxy Version: dev
Commit: 308db49 (fresh dev)
To Reproduce
never run galaxy
clone galaxy into /foo
cd /foo; ./run.sh
logs are in /foo/database/gravity
clone galaxy into /bar
cd /bar; ./run.sh
logs are still in foo/database/gravity; gravity dir not created in bar/database
Expected behavior
Unless I am mistaken, the correct value should be exported in .venv/bin/activate (the code is there).
The text was updated successfully, but these errors were encountered:
@ic4f Cannot reproduce by following your instructions, are you sure you don't have manually set GRAVITY_STATE_DIR in your terminal? Since #13685 Galaxy respects that setting if it's exported in the environment.
That's it! However, this happens if you manually activate the venv. Deactivating it does not unset it, obviously - so it persists. That's one downside of hacking the activate script in the venv, I'm afraid.
Describe the bug
Installing a fresh clone to a new location (after having run galaxy from a different location) and running via run.sh will reuse the value of
GRAVITY_STATE_DIR
from previous installation.Galaxy Version and/or server at which you observed the bug
Galaxy Version: dev
Commit: 308db49 (fresh dev)
To Reproduce
cd /foo; ./run.sh
/foo/database/gravity
cd /bar; ./run.sh
foo/database/gravity
;gravity
dir not created inbar/database
Expected behavior
Unless I am mistaken, the correct value should be exported in
.venv/bin/activate
(the code is there).The text was updated successfully, but these errors were encountered: