See:
From @joshmoore ome/ansible-role-omero-server#41 (comment)
Versions and their sources that I can think of:
- bundle: etc/omero.properties
- omero-py: omero_version.py
- omero-web: omeroweb/version.py
- omero-dropbox: (not yet defined)
- each plugin: (not yet standardized)
- jars: each manifest
From @joshmoore ome/ansible-role-omero-web#27 (comment)
Another option would be a Pipfile-like approach where a requirements-in.txt lists the unversioned files, and then the output of pip freeze records exact tested versions. (i.e. basically the same but outside of the setup.py file)
We could have an omero-release.json artifact which describes all recommended dependencies (perhaps even including OMERO-server.zip?). The general idea is to have a file that describes all suggested production dependencies separate from any single release artifact.
Note this is in YAML format because it's easier to type and read but the real file would be JSON.
# This is some sort of package version, so dependencies can be bumped
# without a new OMERO.server release
version: 6.0.0-1
server:
version: 5.6.0-m1
OMERO.server: https://downloads.openmicroscopy.org/omero/5.6.0-m1/artifacts/OMERO.server-5.6.0-m1-ice36-b125.zip
python-requirements:
omero-py: 5.6.dev4
omero-dropbox: 5.6.dev1
jinja2: 1.2.3
numpy: 1.2.3
pillow: 1.2.3
tables: 1.2.3
web:
version: 5.6.dev4-1
python-requirements:
omero-web: 5.6.dev4
omero-py: 5.6.dev4
redis: 1.2.3The advantage of a dict instead of the name==version from requirements.txt is it should be easier to parse and override in Ansible and other tools, e.g. by merging the web.python-requirements dictionary with a variable omero_web_python_requirements_override (needs to verify this works).
See:
From @joshmoore ome/ansible-role-omero-server#41 (comment)
From @joshmoore ome/ansible-role-omero-web#27 (comment)
We could have an
omero-release.jsonartifact which describes all recommended dependencies (perhaps even includingOMERO-server.zip?). The general idea is to have a file that describes all suggested production dependencies separate from any single release artifact.Note this is in YAML format because it's easier to type and read but the real file would be JSON.
The advantage of a dict instead of the
name==versionfromrequirements.txtis it should be easier to parse and override in Ansible and other tools, e.g. by merging theweb.python-requirementsdictionary with a variableomero_web_python_requirements_override(needs to verify this works).