upgrade subworkflow button doesn't pop up

[remram44]

It only pops up if the containing pipeline is reloaded.

This is a regression I have bisected to the api-changes branch, somewhere in de9cea46...f7c85d7b (abstractions don't work between these).

[dakoop]

Not sure what exactly is going on, but my suggestion would be to chase the is_abstraction flag and make sure the right things are being set.

[dakoop]

Perhaps the shortcut in "if not locator return" in vistrails.core.application:VistrailsApplication.open_vistrail is happening too early?

if not locator: 
    return 
    controller.is_abstraction = is_abstraction 

[rexissimus]

5076da5 fixes is_abstraction not being set. This should fix most described problems.

Subworkflows were being saved incorrectly which caused a lot of issues. They are now saved correctly and reloaded automatically. And the upgrade button appears.

[remram44]

I can't open a workflow that I saved that is using a subworkflow module. It looks like the namespace UUID changes everytime I change the subworkflow...

[rexissimus]

I cannot reproduce this. Did you create them before the fix?

[rexissimus]

Ok, I think I see it now.

[rexissimus]

I think the namespace UUID is supposed to change, but I am not sure how that works. The files looks correct, so it looks like a problem with the subworkflow or upgrade code.

[remram44]

I think the namespace UUID is supposed to change

I don't think so, that breaks each and every workflow referencing it.

[dakoop]

The namespace UUID is supposed to change if the file is saved to a different space. The idea is that a user could have the same subworkflow opened from different vistrails, and they could differ because of changes made locally (to that file) by the users. Thus, we create new UUIDs when we save to different places. I don't recall how the current implementation works, but it may be something like "if a subworkflow is ever saved, assign it a new UUID". I am surprised that the vistrail is not updated with the new information, however. That would definitely be a bug.

[remram44]

The opened vistrail should be updated with the new UUID? That would still break any vistrail that is not open at the time!

I did not save it to a different place, I just used Ctrl+S.

[dakoop]

It depends on the origin of the subworkflow. When it is in "My Subworkflows", we should not change the UUID, but for portability, when we save a vistrail to a file, we also save the subworkflows with it. In such cases, we do not know what the origin of the subworkflows is, and therefore change the UUID since another user that opens that file and has their own version of the subworkflow locally may not want to "contaminate" that version with the one from the saved vistrail. UUIDs for subworkflows in packages should not be changed except by the package developer.

[remram44]

Well, local subworkflows are broken then; I don't know about the other origins.

[rexissimus]

Fixed by df96ac1, caused by d6779b8.

get_descriptor_by_name reported MissingModuleVersion, but since the namespace was different it should have reported MissingModule.

The current namespace always changes when updating local subworkflows. Previous subworkflow versions are loaded from the .vt file. package.descriptor_versions is used to handle multiple versions of the same subworkflow.

[remram44]

I don't get the point of changing the namespace. Wasn't that the point of internal_version?

Also, these bundled subworkflows are just confusing. The subworkflow module has a "!" marking it as upgradable, but if I close and reopen the vistrail, then it's not displayed anymore (because the bundled subworkflow is referenced instead of the local one). There is no way to update short of recreating the module, every single time I open the vistrail, even if I import from the vistrail to my local subworkflows, which would also show an "name already exists".

[remram44]

This also means that if you save to a .xml instead of .vt file, you will never be able to even open that file again if any of the local subworkflows change.

Also there is no way that I can find to delete local subworkflows.