Importing several packages with interdependencies does not allow to correctly set the pre-requisites

[gcotelli]

When using the Tonel application import option if you select several applications to import that depends on themselves you cannot specify it on the pre-requisites step.
For example:
I have two packages Buoy-Assertions and Buoy-Conditions, and Buoy-Assertions depends on Buoy-Conditions. When I try to import all this packages at the same time since the importer offers to select the pre-requisites of Buoy-Assertions first and Buoy-Conditions is still not imported I cannot select it as pre-requisite.

Maybe an option will be to include all the future applications I will import in the pre-requisites dialog, so I can already configure the pre-requisites right without having to create a new version of the application, once all the packages are imported.

[eMaringolo]

It won't be straightforward to specify a non-imported "application" as prereq, since the prereqs contains names of existing Applications in the Library, but what might be needed is to specify the order of loading. So if you first import Buoy-Conditions, then you'll able to import Buoy-Assertions with Buoy-Conditions being already in the Library.

[marianopeck]

Hi @gcotelli
Thanks for the report.

On the one hand, Tonel is just a file format, not a dependency manager. But, on the other hand, ENVY apps, do support "prereqs" and so, we would do our best to support that with Tonel.

For this particular case of you, were you are importing from Pharo, I don't see any way we can guess the dependencies and the correct order of load. What you can do at this point is that you specify the order on which to load the apps by passing an OrderedCollection with the correct order.

If you see when we write to tonel from VA, we do store prereqs info in a custom vaPrerequisites key in the package.st. This was intended mostly for already-loaded-dependencies like Kernel, CommonGraphics, CommonFileSystem, etc. But...that info is not yet being used to possibly compute the "order" of the apps to load in case there are dependencies between them. We would take a look to implement this, but it won't still solve your issue because you don't have vaPrerequisites on your Pharo files.

[marianopeck]

BTW, if you are using Metacello on Pharo, you can use the methods record and similar to obtain the list of packages on LOAD ORDER..that way, you don't have to guess, but you let Metacello tell you the list in order.

[eMaringolo]

Once you have the order of the Package dependency you can do the following:

| reader |
reader := TonelReader new readPackagesFrom: (CfsPath named: '..\path\to\repo').
(TonelLoader on:  reader) loadApplications: #('Buoy-Conditions' 'Buoy-Assertions').

[gcotelli]

I don't know if it's feasible but in the future maybe we can provide a plugin for Iceberg that enables something like "VAST compatibility mode" , so it can preserve the VA-specific metadata when loading code in Pharo and can export the files including that metadata when commiting code changes.
Now this is more easily said that done, but can be a good long term solution.

In the meantime maybe the import tool can ask the user to order manually the packages to import in the UI so I don't have to import it one by one (I do know the right loading order but having to select each file by hand is cumbersome)

[marianopeck]

OK. Much clearer now. The only thing I would like to clarify is that you could also load them via code (no GUI) in which case you can specify the order and hence you don't need to load one by one. What we miss is a way to order them in the BUI.

[eMaringolo]

Currently the dependency between packages cannot be computed automatically, and the feature to load several apps (from packages) is a convenience, but at the lower level apps are loaded independently, you can specify it manually via loadApplicationsNamed: or specifying the order in the UI (screenshot below), and the loader will honor that order.

The only workaround I find today is to specify the load order manually and/or load one by one, which in practice is the same that the TonelLoader does, since it intantiates a TonelApplicationLoader for each "root" application.

[eMaringolo]

The loader is smart enough look in the applications being loaded to load them as dependencies first or as base edition dependencies.

[eMaringolo]

@gcotelli Can you confirm whether this works for you?

[marianopeck]

We got no response, so closing the case.
Also, I think we recently added a lot of support for the compue of pre-requisites, so I am pretty sure @gcotelli will find a strategy that works for him