Possible hashing inconsistencies

[hinerm]

When working on the I2k-2022 PyImageJ notebooks I had been testing with fiji-2.3.1 and then eventually upgraded to fiji-2.5.0. However, my PyImageJ ended up running with 2.3.1 jars inside the 2.5.0 folder. I deleted my jgo cache and re-initialized, and got a 2.5.0 folder with the correct jars.

In this image we can see that the fresh 2.5.0 folder (top) contains different jars than the updated 2.3.1->2.5.0 folder (bottom) but both folders are named with the same hash:

And here is the origin 2.3.1 folder with an appropriately distinct hash:

It's almost like jgo created the 2.5.0 folder correctly but then copied the 2.3.1 contents?

In any case, clearing the cache resolved the issue. But it would be good to reproduce this event.

[ctrueden]

@hinerm Thanks for filing this. I also had that problem, where I got net.imagej:ij:1.53f in a fresh sc.fiji:fiji:2.5.0 environment. I then deleted my ~/.jgo cache folder and reinitialized and the problem was gone, with net.imagej:ij:1.53r as expected. We should definitely get to the bottom of this!

[ctrueden]

This is a really serious problem:

$ rm -rf ~/.jgo
$ python -c 'import imagej; print(imagej.init("2.4.0").getVersion())'
2.4.0/1.53r
$ python -c 'import imagej; print(imagej.init("2.5.0").getVersion())'
2.4.0/1.53r
$ rm -rf ~/.jgo
$ python -c 'import imagej; print(imagej.init("2.5.0").getVersion())'
2.5.0/1.53r
$ python -c 'import imagej; print(imagej.init("2.4.0").getVersion())'
2.5.0/1.53r

😵‍💫