Opened 6 years ago
Last modified 6 years ago
#5427 new enhancement
Proper handling of library versions in OMEdit
Reported by: | Francesco Casella | Owned by: | Adeel Asghar |
---|---|---|---|
Priority: | blocker | Milestone: | 2.0.0 |
Component: | OMEdit | Version: | |
Keywords: | Cc: | massimo ceraolo, Rüdiger Franke, Adrian Pop, leo.gall@…, Martin Sjölund |
Description
The current handling of library versions in OMEdit is quite limited. If a package is opened that has a uses annotation, and the used library is installed in the modelicapath, then it is loaded automatically. However, all kinds of version conflicts are not handled at all, the user just gets this message:
Scripting Warning: Requested package NNN of version x.y.z, but this package was already loaded with version a.b.c. You might experience problems if these versions are incompatible.
which belongs to the category of the error messages that may scare off inexperienced users, who may wonder: what problems, and, what can I do about it?
In particular, the latest version of MSL is pre-loaded in OMEdit, which is a good idea if one wants to start a new project, but may lead to problems if one is using code that requires an older version for any reason.
MSL 4.0.0 is planned to be rolled out in one year, and it will not be backwards compatible, thus requiring conversion scripts. We may expect that for some time people may want to keep on using MSL 3.2.3, so by that time, we need to have a comprehensive user-friendly solution in place.
This is a first sketch of the user requirements, but I think we should iterate on it until we find it completely satisfactory.
- OMEdit preloads the latest version of the MSL at startup (or a previous version, if specified in the OMEdit setup, this could be handy during the MSL 4.0.0 transition).
- When a package is loaded that uses a previous version of an already loaded package (including the MSL), a dialog should be provided with the options of
- unload the current version of the used library and load the older one instead, either from modelicapath, or by opening a file
- update the loaded library to the current version of the used library, running conversion scripts if necessary (see #5297)
- keep using the current library without updating the loaded library (assuming you know what your're doing, do it at your own risk).
This mechanism should work consistently even in the case of multiple dependencies; for example, if I first load library A that requires MSL 3.2.2 and I decide to load that instead of MSL 3.2.3, if I then load library B that wants 3.2.3 instead we can't just unload MSL 3.2.2, because that would break library A. I still don't know exactly what is the best way to handle these situations, I guess we should brainstorm a bit.
In case the conversion ( noneFromVersion = VERSION-NUMBER)
is present, the dialogs should make it clear that the conversion requires no changes and it should not generate issues. The presence of conversion scripts, once supported, should be notified, and we may suggest the user to check the library release notes for news about the updates.
It would be nice if the version annotations contained library-specific information about the conversion, maybe we should make this proposal to the MAP-LANG group.
Change History (4)
comment:1 by , 6 years ago
Cc: | added |
---|
comment:2 by , 6 years ago
Cc: | added |
---|
comment:3 by , 6 years ago
comment:4 by , 6 years ago
I wholeheartedly subscribe to 100% of Leo's observations :)
Thanks for posting comment:3
When using a newer version of OpenModelica, the cited warning struck me, as well! "If these versions are incompatible". How would I find this out?
Some comments from my side:
Related MAP-LANG tickets
I think it's currently very hard for Modelica tools to do a good job, because the language is missing crucial features for library developers, so they could define "compatibilty regions" or "supported/tested combinations of libraries".
Think about Buildings Library: if the next version could state "I'm compatible with MSL 3.2.2 and 3.2.3" then OpenModelica could load MSL 3.2.3, open Buildings library and automatically convert a user package to MSL 3.2.3. In this case, it would not be perfect to stick to MSL 3.2.2.