search

BIOP / abba_python

ABBA, controlled from python
Other
6 stars 3 forks source link

Add info on update #18

Open carlocastoldi opened 3 weeks ago

carlocastoldi commented 3 weeks ago

Hi!

I think i don't fully understand how BIOP Plugin updates work through abba_python. For instance, by installing through ImageJ, i see that that the current version is /opt/Fiji.app/jars/ImageToAtlasRegister-0.8.2.jar. However abba_python asks for v0.8.0: https://github.com/BIOP/abba_python/blob/61d1a310805e63f7cc93f2872ebcff8ff5e7e6c1/src/abba_python/abba.py#L18 And i think it finds it in $HOME/.m2/repository/ch/epfl/biop/ImageToAtlasRegister/0.8.0/ImageToAtlasRegister-0.8.0.jar, right?

If you update the version over there to match ImageJ's, will it update automatically? Should we always run pip install abba_python --upgrade?

Thank you!

NicoKiaru commented 3 weeks ago

My way of thinking was: in abba_python you shouldn't run any updates on the java side.

When releasing the Java version 0.8.0 I also released abba_python and set its version to 0.8.0 as well; in order to start having matching versions; but that's artificial, and for convenience (at least I hope it is and avoids confusion).

Then, each time I perform an update I should:

So currently, I've done an update on the Java side (0.8.2), but I did not release the new version in python yet. So abba_python 0.8.0 still uses the java jar 0.8.0

While it may be possible to update jars while keeping abba_python to 0.8.0, I don't think it's a good idea.

Is it slightly clearer ?

Of course combining java and python means that we double the pain of versioning (yeepee)

Also, I have this installer which is convenient for windows people, and I need to release it as well - it's stuck to 0.8.0 because abba_python 0.8.2 do not exist yet.

My way of thinking the abba update process:

  1. update on the java side
  2. release the jar on maven x.y.z
  3. (deploy 1) upload abba on the PTBIOP update side (java only)
  4. update abba_python to use the new jar x.y.z
  5. (deploy 2) release the new abba_python on pip, set its version to x.y.z
  6. update the windows installer to use abba_python x.y.z
  7. (deploy 3) release the new windows installer x.y.z

Sometimes it could happen that we need to update python independently of java, in this case I suggest another number x.y.z.1 x.y.z.2 etc.

carlocastoldi commented 3 weeks ago

Is it slightly clearer ?

yes, very much! What i didn't understand from the get go was whether this version of abba was meant to be updated from Update Sites. And obviously, after little digging, it isn't. It is bound to a release cycle that is currently independent from abba_java.

My way of thinking the abba update process:

  1. update on the java side
  2. release the jar on maven x.y.z
  3. (deploy 1) upload abba on the PTBIOP update side (java only)
  4. update abba_python to use the new jar x.y.z
  5. (deploy 2) release the new abba_python on pip, set its version to x.y.z
  6. update the windows installer to use abba_python x.y.z
  7. (deploy 3) release the new windows installer x.y.z

that seems like a good chain to assure that there is no breaking update in the pipeline. Does an user that installed ABBA on windows through the installer (or on Linux through the conda envs) get a warning that they're running an out-of-date version? If so, should they ignore it? If not, how do they know how to correctly update?

From my understanding it's just a matter of entering the conda environment and typing pip install abba_python --upgrade, however this may have to be explicitly written in the README 🤔

Thank you for the very detailed answer!