Open will-moore opened 3 months ago
This issue has been mentioned on Image.sc Forum. There might be relevant details there:
https://forum.image.sc/t/omere-figure-export-pdf-does-not-work/39573/31
This branch of my fork of omero-server-docker adds omero-figure to the python plugins installed in the ansible playbook so it is available in the server image by default and adds a script which auto-updates Figure_To_Pdf.py to the version in the latest tagged release of omero-figure.
It does this by querying the github API to get the hash of the commit of the release and pulling Figure_To_Pdf.py from that commit.
https://github.com/RichardJActon/omero-server-docker/tree/omero-figure-auto-update
Happy to open a PR with this if you approve of the general approach.
@will-moore this applies to any of the apps included in https://github.com/ome/omero-web-docker/blob/master/standalone/Dockerfile
I raised the issue a while back since we only release the docker image on a new release of omero-web
We will need to introduce a new tag e.g. 5.25.0-x
each time a new app is release.
@jburel Are there any issues with using 'exotic' tags like that? One alternative option is to not tie the tag to server version and use e.g. Date-based tags which might make it possible to automate the tag (e.g. https://github.com/dncrews/date-tag although this is a JS-based tool). But that maybe more of a breaking change. Thanks @RichardJActon - I don't know much about Docker, but I would think that if we can automate this as much as possible then that would be a big win.
@will-moore no we already used it. It is something to discuss with the wider group.
As for the automation, we already have things in place via GHA e.g. https://github.com/ome/omero-web-docker/pull/64 We could easily apply the logic for apps.
It occurred to me that there might be a better way of automating getting the scripts from the various packages into the right places in the docker image and ensuring that they are consistent with the installed package versions that does not rely on making potentially brittle API calls to github during the build process.
It depends if python packages have an analog of this feature or not - I'm not sure I've not done a lot of python packaging. In R packages there is a folder inst
that you can include in your package which is the sanctioned way of having files, such as additional scripts, in your package copied directly into the installation directory of the package. If there is an equivalent for python packages then copying or linking the scripts from where they get installed in the venv to the location that OMERO.server expects to find them would be a more reliable approach than the one I initially took - anyone know if the python packaging format officially supports something like this?
It is not just the script , it is also its dependencies that potentially need to be updated. Figure is the only app at the moment that requires a server-side change.
Indeed - so to clarify, the desired sequence of events is:
To be successful the image rebuild with the latest omero-figure needs to:
Setting aside triggering the rebuild with github actions for a moment and thinking about what needs to change in Docker build to update omero-figure, we need as I understand it, to:
There are two approaches I can think of to updating the script(s):
package_data
in the setuptools config https://setuptools.pypa.io/en/latest/userguide/datafiles.html# and copy them to the right place during the docker build.I would suggest that the latter option is the preferable approach as it creates a tight coupling between the package installed and the version of the script being used. It also does not make additional calls to external sources during the image build which are brittle and could fail breaking the image build.
EDIT:
*The web client image should probably also have a rebuild triggered on an omero-figure release so the client is in sync with the server.
See https://forum.image.sc/t/omere-figure-export-pdf-does-not-work/39573/30
On release, we should update the omero-server Docker with the Pdf export script, as well as the omero-web Docker. That way, it will always be installed for users, without needing complex workflows as described above.