I’m trying to run Galaxy on my Mac, a couple of months ago it worked perfectly fine. However, now, I get the following error when trying to run sh. run.sh
41-53-255-53:galaxy nina$ sh run.sh
Activating virtualenv at .venv
./scripts/common_startup_functions.sh: line 105: .venv/bin/activate: No such file or directory
141-53-255-53:galaxy nina$ rm -rf .venv
141-53-255-53:galaxy nina$ sh run.sh
Creating Python virtual environment for Galaxy: .venv
To avoid this, use the --no-create-venv flag or set $GALAXY_VIRTUAL_ENV to an
existing environment before starting Galaxy.
Running virtualenv with interpreter /Library/Frameworks/Python.framework/Versions/2.7/bin/python
New python executable in /usr/local/bin/galaxy/.venv/bin/python
Traceback (most recent call last):
File "/usr/local/bin/miniconda3/lib/python3.6/site-packages/virtualenv.py", line 2884, in <module>
main()
File "/usr/local/bin/miniconda3/lib/python3.6/site-packages/virtualenv.py", line 712, in main
symlink=options.symlink)
File "/usr/local/bin/miniconda3/lib/python3.6/site-packages/virtualenv.py", line 927, in create_environment
site_packages=site_packages, clear=clear, symlink=symlink))
File "/usr/local/bin/miniconda3/lib/python3.6/site-packages/virtualenv.py", line 1233, in install_python
copy_exe_shared_libs_and_symlinks(executable, py_executable, home_dir)
File "/usr/local/bin/miniconda3/lib/python3.6/site-packages/virtualenv.py", line 2843, in copy_exe_shared_libs_and_symlinks
of = codefile(f, rpaths)
File "/usr/local/bin/miniconda3/lib/python3.6/site-packages/virtualenv.py", line 2814, in codefile
return machofile(file, list(initial_rpaths_transitive))
File "/usr/local/bin/miniconda3/lib/python3.6/site-packages/virtualenv.py", line 2437, in __init__
_, sos = zip(*mach_o_find_dylibs(file))
File "/usr/local/bin/miniconda3/lib/python3.6/site-packages/virtualenv.py", line 2401, in mach_o_find_dylibs
do_file(ofile, find_lc_load_dylib, offset_size(), results, regex)
File "/usr/local/bin/miniconda3/lib/python3.6/site-packages/virtualenv.py", line 2370, in do_file
do_file(file, offset_size(offset, size), *args)
TypeError: do_file() takes at least 4 arguments (3 given)
Depending on whether or not you have conda installed, you might need to specifically first create the .venv inside the galaxy directory with virtualenv. Install that first if you don’t have it.
The process goes something like this…
Make sure you are in the galaxy home directory:
$ pwd
/Users/me/1901/galaxy
Create the environment:
$ virtualenv -p /usr/bin/python .venv
Running virtualenv with interpreter /usr/bin/python
New python executable in /Users/me/1901/galaxy/.venv/bin/python
Installing setuptools, pip, wheel...
done.
Startup/initialize Galaxy:
$ sh run.sh
< a bunch of output logging ending with ... >
Starting server in PID NNNN.
serving on http://localhost:8080
Note: This was true last time I checked, and I still do it when starting up a local on MAC OSX. The admins can correct me if no longer needed and something else is going on!
Yes, that is an example path. Yours is fine – just make sure you cd into that directory before running the virtualenv and sh run.sh commands.
It looks like you don’t have virtualenv installed yet. OSX will have pip (one way to install packages) already installed but you might need to update it. So, it may take a few steps, but how-to for all is covered here nicely: Pipenv & Virtual Environments — The Hitchhiker's Guide to Python
Also – I tried installing 19.01 without the python venv (conda instead) and it did start up the server but I haven’t tested it at all yet – might have problems. Python venv is/was better anyway for a few complicated reasons, so this is worth it AFAIK.
Update: Did fine one problem with the default Conda venv method (and there could be others!) – loading a fasa dataset into an IGV local browser fails, for some dependency (possibly Samtools but that is just a guess!).
Even people with administrative experience will start over and use the Python venv rather than attempt to fix the various issues that can come up when using a Conda venv.
So – it is definitely recommended to use a Python venv to avoid unnecessary issues.