We no longer need to translate the arguments of manage_db.sh into
arguments for alembic. The new facade script for alembic (db.sh)
accesses the alembic api programmatically.
This is consistent with other similar pairs of files:
[script-name].sh invoking scripts/[script-name].py (check_model, create_roolshed_db, db)
Also, the python file does not require exec permissions.
For ToolShed, we have create_toolshed_db.sh.
For galaxy and toolshed install databases (gxy and tsi branches under
alembic), we use the `init` subcommand of the `db.sh` script (`./db.sh
init`), which has exactly the same functionality as these deleted
scripts.
To the best of my knowledge, these are not used anywhere else (unlike,
for example, scripts/manage_db.py, which is called from the
ansible-galaxy role).
1. Remove aliases from subcommands that change things (upgrade, downgrade,
revision, init) to reduce risk of accidental usage.
2. Add aliases to readonly subcommands (history, show, version,
dbversion)
3. Minor edits
Rationale: alternate config file applies to all subcommands, so, I
think, it is more correct to run this:
> ./db.sh -c mygalaxy.yml upgrade some-revision-id
than this:
> ./db.sh upgrade some-revision-id -c mygalaxy.yml
That's also consistent with how alembic handles this option.
The new flake8-bugbear 22.7.1 warns if a function defined inside a loop uses
a variable redefined in the loop, due to the late-binding closure gotcha:
https://docs.python-guide.org/writing/gotchas/#late-binding-closures
When possible/sensible, I've moved the function definition before the loop
(adding the variable(s) as parameters) which is clearly also a speed-up.
Most other cases are false alarms, e.g. if the function is used and
discarded within the loop iteration that defines it. In such cases, I've
annotated the offending lines with a `# noqa: B023`.
The only file where I've applied the suggested workaround of immediately
binding arguments is in `lib/galaxy/visualization/plugins/config_parser.py`
Also:
- Small refactorings, in particular to `scripts/apply_tags.py`
instead of directly loading it as YAML.
Will make it easier to uniformly deal with changes of format (e.g.
we are deprecating ini now).
Fix traceback:
```
Traceback (most recent call last):
File "scripts/config_parse.py", line 31, in <module>
main(args.config_file, args.setting)
File "scripts/config_parse.py", line 16, in main
gx_config = GalaxyAppConfiguration(**yaml.safe_load(open(config))["galaxy"])
File "/home/berntm/.planemo/gx_venv_3/lib/python3.8/site-packages/yaml/__init__.py", line 125, in safe_load
return load(stream, SafeLoader)
File "/home/berntm/.planemo/gx_venv_3/lib/python3.8/site-packages/yaml/__init__.py", line 81, in load
return loader.get_single_data()
File "/home/berntm/.planemo/gx_venv_3/lib/python3.8/site-packages/yaml/constructor.py", line 49, in get_single_data
node = self.get_single_node()
File "/home/berntm/.planemo/gx_venv_3/lib/python3.8/site-packages/yaml/composer.py", line 39, in get_single_node
if not self.check_event(StreamEndEvent):
File "/home/berntm/.planemo/gx_venv_3/lib/python3.8/site-packages/yaml/parser.py", line 98, in check_event
self.current_event = self.state()
File "/home/berntm/.planemo/gx_venv_3/lib/python3.8/site-packages/yaml/parser.py", line 171, in parse_document_start
raise ParserError(None, None,
yaml.parser.ParserError: expected '<document start>', but found '<scalar>'
in "/tmp/tmpsffm7of5/galaxy.ini", line 3, column 1
```
when starting Galaxy with a `galaxy.ini` config file (though Galaxy startup
will still fail later).
John Davis