search

ome / design

OME Design proposals
http://ome.github.io/design/
1 stars 15 forks source link

OMERO versions and describing dependencies in a release package file #103

Open manics opened 4 years ago

manics commented 4 years ago

See:

From @joshmoore https://github.com/ome/ansible-role-omero-server/issues/41#issuecomment-553365478

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 https://github.com/ome/ansible-role-omero-web/issues/27#issuecomment-553361243

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.3

The 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).

manics commented 4 years ago

This file can be placed at a well known location e.g. https://downloads.openmicroscopy.org/omero/{latest|6|6.0|...}/omero-release.json, avoiding the need to parse redirects to obtain the latest version number (https://github.com/openmicroscopy/management_tools/pull/1036#issuecomment-510168596)

manics commented 4 years ago

Another use-case: OMERO.web links to an appropriate Insight version based on its version. This is now broken due to the decoupling of OMERO.server, OMERO.web and OMERO.insight versions.

joshmoore commented 4 years ago

@manics additionally realized that the omero-web configuration properties are only exposed as part of the final docs, meaning a doc re-release may be required after an omero-web release.

joshmoore commented 4 years ago

see discussion under https://github.com/ome/ome-documentation/pull/2123#discussion_r417907463 on possible using an omero-server package for handling part of this.

imagesc-bot commented 4 years ago

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/omero-release-versions-and-strategy/38336/5

manics commented 3 years ago

See https://github.com/ome/omero-cli-server/pull/3