I *think* this is a problem with auto-imports. In particular your AtlasImporter script, in line 108, where it uses Project and does not import the full class name.

From hitting 't' and typing 'project' in https://github.com/fiji/TrakEM2 it seems that the class you want is
https://github.com/fiji/TrakEM2/blob/master/TrakEM2_/src/main/java/ini/trakem2/Project.java

Therefore, you have to import it using

    from ini.trakem2 import Project

in your script.

Please understand that auto-imports were tenable as long as Fiji was a puny project, but now it grew to a point where there would be simply too many clashes. Therefore scripts must not rely on auto-imports, ever (just imagine a random plugin being added that implements a 'Project' class? Exactly. You'd be in exactly the same spot as right now, so the removal of the auto-imports is not the problem; the lack of the explicit import is).

Thx, for looking into it.
I'm new to Jython scripting and copied scripts from Albert Cardona's examples and then just modifying tiny bits to get started.
The examples were extremly helpfullto get started, but if the do not work anymore, they should be adapted I think

> I'm new to Jython scripting and copied scripts from Albert Cardona's examples and then just modifying tiny bits to get started.
> The examples were extremly helpfullto get started, but if the do not work anymore, they should be adapted I think

I agree that the examples are helpful and that they should be updated. Hopefully Albert will do that soon.

Lukas,

to fix the scripts, open them in the Script Editor, select a capitalized word, and then go to "Tools - Open help for class (with frames)"

E.g for:

p = Project.getProjects()

... you'll find Project under "ini.trakem2.Project". Therefore, place at the very top of your script an import statement:

from ini.trakem2 import Project


Johannes: given that you have introduced the breaking change, it would be appropriate that the change is not released half-way but it is seen through to completion. I would appreciate very much if you could therefore complete the task by making all the necessary adjustments in examples and documentation alike, prior to releasing it to the world.

> it would be appropriate that the change is not released half-way but it is
> seen through to completion.

In an ideal world, of course. But it is pragmatically infeasible without help from the greater ImageJ community. We cannot accomplish everything alone.

Curtis and Johannes,

releasing a breaking change and expecting everybody, both users and developers, to swiftly adapt, leads to many issues as you have seen, creating work for every developer and confusion for end-users.

A transition could be supported by e.g. startup scripts for every language that include all imports, therefore supporting current working setups as they are without interruption, while providing the opportunity to each user to remove the default imports and therefore avoid class name clashes. At least this you could implement to support the currently breaking change.

After announcing this change, then there is an opportunity for all developers to use a grace period for adapting scripts and documentation, and for end -users to be forewarned. Eventually the default imports could be removed. If one such announcement was done long ago, I am afraid myself and all end-users missed it.

> releasing a breaking change and expecting everybody, both users and
> developers, to swiftly adapt, leads to many issues as you have seen,
> creating work for every developer and confusion for end-users.

Absolutely agreed!

> A transition could be supported

Yes. It is a question of time and priorities. We are at the limits of our bandwidth fixing issues which affect many more users in more situations than the auto-import scripting issue does.

There is an opportunity cost for everything. On the surface your proposal is absolutely correct and reasonable, but you have to weigh it against what will _not_ be done as a consequence. The only way I know of to mitigate this is on the "supply side": more people pitching in to help -- the "scratch your itch" philosophy of open source.

Curtis,

if time is at stake, then perhaps the introduction of a breaking change was not a good decision at this point.

Keep in mind that the interpreters, with their autoimports, are what transform Fiji from an expanded ImageJ to something akin to Matlab: an interactive environment for developing and testing out programs, and executing complex pipelines piece-wise thanks to the persistence of state.

Breaking this is hard to understand from an end-user point of view, and a devastating blow to the usability of Fiji for a lot of users.

Demanding that an end-user knows where to find basic ImageJ classes is burdensome for beginners, while advanced users would have no issue with an announcement that stated "from now on, run this script (URL) in your interpreters when you open them, which supplies all the imports which are no longer imported by default".

In retrospect, the interpreters should have always have had, as they did, the default imports (or an "environment" pull down menu to choose e.g. all of ImageJ, all of TrakEM2, etc.); it is the Script Editor and the execution of scripts that should not have had them.

Albert

> if time is at stake, then perhaps the introduction of a breaking
> change was not a good decision at this point.

I am sorry you are disappointed with the direction of the project. I truly hope you are in the minority, but satisfied people are rarely as vocal as those unsatisfied. If it is truly important to you, I urge you to participate at a more direct and technical level (i.e.: coding). Otherwise, please understand that this project is driven by the needs of those who _do_ participate.

> a devastating blow to the usability of Fiji for a lot of users.

I agree that ImageJ should keep the interpreter functionality. It will be reworked to be language agnostic, in line with the rest of the scripting framework. If you desire this to happen more quickly, consider allocating some of your resources towards that goal.

> Demanding that an end-user knows where to find basic ImageJ classes is
> burdensome for beginners

Agreed, we probably want an "organize imports" style feature that tries to add the imports at the top of the script.

Curtis,

> I agree that ImageJ should keep the interpreter functionality.
> It will be reworked to be language agnostic, in line with the
> rest of the scripting framework. If you desire this to happen
> more quickly, consider allocating some of your resources
> towards that goal.


The efforts you guys are putting in are fantastic. What I object to is the removal of functionality that a lot of Fiji users rely on, without having a ready replacement. Demanding that others produce said replacement quickly, so that the gap is not long, is not acceptable--we all have our schedules and priorities.

Albert