Renaming of OMERO.figure to ome-figure

[will-moore]

In order to advertise the fact that the "figure" app is available to the broad community of non-OMERO users, I think we need to drop "OMERO" from the name. Many users will simply ignore the app if it is called OMERO.figure, and never find out that it can support OME-Zarr without OMERO. E.g. see the discussion at AllenInstitute/biofile-finder#547

We could rename to https://github.com/ome/ome-figure OR https://github.com/ome/figure ?
Searching GitHub for "figure" repos only finds this one match: https://github.com/pibook/figure but there is https://pypi.org/project/figure/ package

Renaming Options:

• omero-figure AND ome-figure: We could create a standalone ome-figure JavaScript app and let that be consumed by the existing omero-figure app. This would be similar to biofile-finder and omero-biofilefinder:
  • Pros:
    • Possible to apply different licences. E.g. MIT for ome-figure and GPL for omero-figure.
    • The omero-figure GitHub repo stays put.
    • Can still say "OMERO.figure is renamed to ome figure", at https://github.com/ome/figure
  • Cons:
    • Burden of keeping 2 repos in-sync with new features, updates etc. For omero-biofilefinder we manually bundle BFF app into static files.
    • The Figure_To_Pdf.py script has omero dependencies (would need to be GPL) but is also required for standalone app workflow. Which repo would it live in? If it stays in omero-figure, then keeping both apps in sync with new features is tricky.
    • There's quite a bit of JavaScript code that is specific to the OMERO use-case: interacting with OMERO json endpoints etc. Not ideal to move this to the ome-figure repo (would it need to be GPL?), but very tricky to extract it out.
    • User/dev confusion. How are the 2 apps related? What code is where? Need 2 PRs in different repos for each new feature. More complex developer workflow. Where do users create GitHub issues? etc.
• Full rename of omero-figure to ome-figure. Rename the GitHub repo, package names etc etc.
  • Pros:
    • All the code stays together in 1 app. Relationship between different parts of the code (JS app, omero-web plugin, Figure_to_Pdf.py) stays the same as it is now
    • Only 1 repo to update with new features. Easier dev workflow - same as now.
  • Cons:
    • Lots of work to rename everything. BIG breaking change; hard to do this incrementally.
    • Upgrading for users would be more work. pip uninstall omero-figure, remove from omero.web.apps list. Then install and add ome-figure
• Do nothing, keep omero-figure as it is now.
  • Not an option: see motivation at the intro above

There are a wide range of places where the renaming will need to take place. Some are just text/labels while others are more critical package names, urls, methods etc.

• Repo name: change omero-figure to ome-figure. See https://docs.github.com/en/repositories/creating-and-managing-repositories/renaming-a-repository "When you rename a repository, all existing information, with the exception of project site URLs, is automatically redirected to the new name, including: issues etc.."
• Package rename on pypi: see https://peps.python.org/pep-0423/#how-to-rename-a-project
  • NB: Could be tricky to publish new ome-figure package (with the renamed repo etc) and then push a "final" release to omero-figure?!
• Code changes associated with package renaming: imports etc. Many "omero" naming won't need to change, since it's code for interacting with OMERO etc.
• https://www.openmicroscopy.org/omero/figure/ can stay same URL etc. This is now "The Figure app is available in OMERO". Replace "OMERO.figure" with "OME's Figure app" etc.
• https://omero-guides.readthedocs.io/en/latest/figure/docs/ URL no change. Need to replace "OMERO.figure" with "ome-figure" or "OME's figure app".

[will-moore]

ome-figure or just figure?

It would be nice to have a repo named https://github.com/ome/figure (which I think was the original name, since that link currently redirects to omero-figure).
That would give us a static app at https://ome.github.io/figure/ which is nice (although I guess we could always register a domain and point it at the github deployment? but that's more work etc.)

When users want to install the Figure_To_Pdf.py script, (currently this is pip install --pre "omero-figure[export]") we can't use just figure here since https://pypi.org/project/figure/ already exists.
So we probably need a ome_figure package name and pypi project. Then, local installation of the script is just pip install "ome-figure"

The simplest scenario is to have pip install "ome-figure" include the full script (in it's current form) from omero-figure. The only issue with this option is that ome-figure will have the GPL omero-figure as a dependency, so will also have to be GPL, even though it doesn't need the omero code.

Alternatively, we could have ome-figure (containing the export script) as a dependency of omero-figure, with omero-figure extending the export script to add various interactions with OMERO: rendering images and saving PDF/TIFFs as File-Annotations.
This could mean removing all the OMERO code from Figure_To_Pdf.py and making sure that the classes in there could be subclassed to add OMERO rendering/saving behaviour. Also, the omero.script logic would stay in omero-figure repo.

If the JavaScript web app and the Figure_To_Pdf.py base code are both in https://ome.github.io/figure/, then how is that consumed within omero-figure?

git submodule or git subtree

I don't have a clear preference for submodule or subtree, but I think I understand submodule a bit better and I think that would work well.
Currently, npm run build compiles the JavaScript, CSS & html into a build directory AND copies everything to the correct location in the Django app's /static and /template directories.
I guess we could have the npm run build command in the figure app, as a submodule within omero-figure/figure and when you cd figure && npm run build it could do the build, and then check whether a parent ../omero-figure/omero_figure/static directory exists. If it does, then copy assets there.

[joshmoore]

Random thoughts:

• there are repos that have an [extra] install with a different license, so I assume we could do the same.
• extracting out a "higher-level" ome-figure feels like the right thing to do rather than just rename.
• the repo & url can be /figure but still use ome-figure on pypi

[will-moore]

OK, I think I'm becoming clearer on where we want to end up:

• New figure repo that contains all the JavaScript code and an ome-figure python package for local export (where the main script code goes and relationship between omero-figure and ome-figure can be decided/evolved as we go).
• The figure repo is a submodule of omero-figure

I started the first moves towards this, but then I realised that this would be a massive amount of work during which time the app would be unreleasable. We have an v8.0.1.rc2 release candidate, which I think we should release as v8.0.1 (including #686 - updated to remove "release candidate" caveat). Also need to remove --pre from pip install --pre "omero-figure[export]" in the README.
For OMERO users, that release would add the support of OME-Zarr images to omero-figure. For anyone using the standalone app, the release would have no effect since the static app is currently deployed from master branch.