Make Galaxy (almost) packageable/installable#921
Make Galaxy (almost) packageable/installable#921jmchilton merged 60 commits intogalaxyproject:devfrom
Conversation
|
💯 !! |
|
api tests on Jenkins report |
|
this needs to be rebased or dev merged into it before jenkins can test |
|
@martenson Waiting for the tests to pass on #428 first. |
setup.py
Outdated
| if GALAXY_PACKAGE == "galaxy-lib": | ||
| requirements = [] | ||
| base_packages = [ | ||
| 'galaxy.datatypes', |
There was a problem hiding this comment.
Datatypes depends on models so it shouldn't live in galaxy-lib in my opinion.
|
What made you decide what to put in
I would start from the bottom and introduce one or so a year as we refactor around these new distinctions? There are a think both practical and abstract design goals with each of these distinctions that I could go into in depth. None of this feels like something that should be rushed though. |
"This seems like a web package", "This doesn't". Which is why it's almost certainly wrong. So for now perhaps we should just have |
|
It would be nice to make the final tool migration (xref. #636) before this PR is merged. |
|
Per conversation with @jmchilton we are going to add a |
99faf51 to
88c01d7
Compare
if you install it and then run `galaxy` from the root of a Galaxy clone, after installing all the dependencies (see the end of ./scripts/common_startup.sh), it should start.
another story), fix classifiers.
tool-shed packages (see galaxyproject#1396). Lots of path fixing to be done still.
wheels and packages.
"installed Galaxy" world is not the current working directory.
live in the `galaxy` package. Install deps at install time.
lib/galaxy/config/sample/
Fix comparisons of relative and absolute paths like the one described at galaxyproject#921 (comment)
| return os.path.join(self.sample_config_dir, path) | ||
|
|
||
| def _parse_config_file_options(self, defaults, listify_defaults, config_kwargs): | ||
| for var, defaults in defaults.items(): |
There was a problem hiding this comment.
Probably it's not a bug, but reusing defaults variable name as loop variable is surely confusing.
There was a problem hiding this comment.
Yes!! I noticed it and hated it on first site.. I'll submit a quick PR (didn't want to trigger a code review over such a minor thing - but since you mention this.. so thanks :)
There was a problem hiding this comment.
@nsoranzo How about defaults >> vals?
for var, vals in defaults.items():
if config_kwargs.get(var, None) is not None:
path = config_kwargs.get(var)
setattr(self, var + '_set', True)
else:
for val in vals:
if os.path.exists(resolve_path(val, self.root)):
path = val
break
else:
path = vals[-1]
setattr(self, var + '_set', False)
setattr(self, var, resolve_path(path, self.root))
There was a problem hiding this comment.
Maybe values/value to make it a bit more different from var.
| setattr(self, var + '_set', False) | ||
| setattr(self, var, resolve_path(path, self.root)) | ||
|
|
||
| for var, defaults in listify_defaults.items(): |
| try: | ||
| tool_conf_source = get_toolbox_parser(config_filename) | ||
| except (OSError, IOError) as exc: | ||
| for opt in ('shed_tool_conf', 'migrated_tools_config'): |
There was a problem hiding this comment.
fresh on dev this is called twice with config_filename=/Users/marten/devel/git/temp/galaxy/config/migrated_tools_conf.xml but once it has getattr(self.app.config, opt) equal to /Users/marten/devel/git/temp/galaxy/config/shed_tool_conf.xml.
so the _dynamic_tool_confs end up being
[{
'tool_path': '/Users/marten/devel/git/temp/galaxy/database/shed_tools',
'create': '<?xml version="1.0"?>\n<toolbox tool_path="/Users/marten/devel/git/temp/galaxy/database/shed_tools">\n</toolbox>\n',
'config_filename': '/Users/marten/devel/git/temp/galaxy/config/migrated_tools_conf.xml',
'config_elems': []}]which seems wrong?
There was a problem hiding this comment.
Can you create an issue and assign me?
There was a problem hiding this comment.
The issue is here: #8484 and you are assigned to it.
There was a problem hiding this comment.
Ah, didn't realize this was the same thing, thanks.
for config files. Broken in galaxyproject#921 . For context, see galaxyproject#8639 (comment) Includes also elimination of `resolve_path` function as in galaxyproject#8646
for config files. Broken in galaxyproject#921 . For context, see galaxyproject#8639 (comment) Includes also elimination of `resolve_path` function as in galaxyproject#8646
Addresses this comment: galaxyproject#921 (comment)
Fix comparisons of relative and absolute paths like the one described at galaxyproject#921 (comment)
1. Split method body in two 2. Change assignment of config_dir when running from source 3. Ensure value of config_dir is an absolute path I think splitting the method imporoves readability: its functionality can be easily grouped into 2 parts: (1) finding and reading the main config file (I've removed the comment because it was not quite in place and, I think, not essential to understanding the code); and (2) setting paths for core config properties based on part (1). The change to config_dir addresses previous discussions: galaxyproject#8894 (comment) galaxyproject#921 (comment) I could've changed the line in question: galaxyproject#921 (comment) to this: `if self.config_file is None and `config_dir` is not in config_kwargs:` However, in my opinion, such an edit would further obfuscate the logic of assigning that value. The proposed solution, I think, although more verbose, makes the code more straightforward: it is immediately clear what values are assigned under what circumstances. Finally, in the previous version `config_dir` can be a relative path if `config_file` exists, but `config_dir` is set by the user (to a relative path). That, I believe, was a bug.
2019 Update
This won't be entirely ready for
pip install galaxybut does what's needed to quickly finish it up. The plan is for the galaxy-web-apps package package essentially a full install of Galaxy with its web stack, and the galaxy metapackage will be pinned to stable releases. Because the packagification of Galaxy began just before updating this PR happened, the method originally used here (one big package) is no longer valid, and the metapackage isn't working yet. That will happen in a subsequent PR.This PR includes some important useful pieces:
GalaxyConfiguration.config_dirisdirname(config_file)(or.if there is no config file)GalaxyConfiguration.data_diris./datacwdisgalaxy_root./config/lib/galaxy/config/sampleThe exception to the changes above: if running from
cwd = galaxy_root, thenconfig_diranddata_dirare<cwd>/configand<cwd>/databaseas before.Updated TODO list for the next PR
galaxy-configfor YAML configsgalaxy-uwsgiorgalaxy -m uwsgistatic/external_services/,tool-data/, ...galaxy-set-metadatacommand to replace the tempfile method currently usedgalaxy-manage-dbto galaxy-app after package-ify top-level Python files in lib/galaxy. #8293 I thinkOriginal PR
Building on #428, this attempts to make Galaxy installable via the standard Pythonic mechanism. To use:
PYTHONPATH= pip install --upgrade pip wheelmake wheelsPYTHONPATH= pip install -i https://wheels.galaxyproject.org/simple/ 'dist/galaxy-16.7.dev0-py2-none-any.whl[postgresql]'config/galaxy.ini.sampleto it asgalaxy.inigalaxy-paster serve galaxy.iniAlternatively:
PYTHONPATH= pip install --upgrade pipmake clientPYTHONPATH= pip install -i https://wheels.galaxyproject.org/simple '.[postgresql]'(add-efor editable/develop mode)TODO list
lib/galaxy/datatypes/converters/,lib/galaxy/datatypes/set_meatadata_tool.xml, etc. (just use__file__rather than assuming cwd is galaxy_root?)galaxy-maingalaxy-configto create a Galaxy config directory and relevant contentsconfig_diroption to galaxy.inished_tool_conf.xmlto its own config variableshed_*configs to exist (they can be created as necessary)Install custom pipnot neededtools/templates/and make it findable by Galaxystatic/and make it findable by Galaxyexternal_services/,tool-data/, ...galaxy-set-metadatacommand to replace the tempfile method currently used