modelica / ModelicaSpecification

Specification of the Modelica Language
https://specification.modelica.org
Creative Commons Attribution Share Alike 4.0 International
102 stars 41 forks source link

Uses annotation should support mutliple libraries #1023

Open modelica-trac-importer opened 6 years ago

modelica-trac-importer commented 6 years ago

Reported by fcasella on 13 Mar 2013 15:19 UTC The uses annotation allows to specify a single version of a certain library that another library depends upon. This is too restrictive. Library X might work perfectly well with multiple versions of library Y, so it is really inconvenient to have multiple versions of X which only differ because of a different uses annotation.

This problem has been around for years. It is related to #132, #536, #573, but in my opinion it should be fixed as soon as possible, without waiting for any of those proposals to coalesce into an official specification, which might take some more years because of their complexity.

My very simple proposal is to allow specifying an ordered list of libraries in the uses annotation, e.g.,

annotation(uses(Modelica(version="3.2.1", version = "3.3")));

similarly to the noneFromVersion conversion annotation.

The Modelica tool will load the latest available/supported/tested/licensed version (i.e., the one one corresponding to the latest possible element in the comma-separated list) or, in case of multiple dependencies among different libraries, the latest possible version that fits the requirements of all the other loaded libraries.

The specification and the implementation looks straightforward, and if all tool vendors agree, we could add this to 3.3 rev1, without having to wait for 3.4. Shall I file an MCP for this?


Migrated-From: https://trac.modelica.org/Modelica/ticket/1023

modelica-trac-importer commented 6 years ago

Comment by sjoelund.se on 13 Mar 2013 15:38 UTC I would make some changes to this... You may not modify the same component twice (which you do in this example).

See 12.9.4 to see how the Library annotation deals with multiple choices (it allows either version="3.2.1" or version={"3.2.1","3.3"}). I personally do prefer that way of handling these things even though it is weird since you are allowed to use a scalar for something that takes an array...

modelica-trac-importer commented 6 years ago

Comment by mtiller on 13 Mar 2013 15:48 UTC I would strongly prefer to see us focus on #573 that to come up with yet another proposal. There has already been quite a bit of discussion around #573 (on this topic).

modelica-trac-importer commented 6 years ago

Comment by hansolsson on 15 Mar 2013 09:25 UTC This proposal seems like a good change.

As for the implementation: most of the issues for version-handling occur when there is a need to update libraries (since we currently have no mechanism for detecting if the library will stay compatible with both versions).

A simple solution for that is to restrict it to "read-only" libraries (that could be viewed as a tool-issue).

This goes together with viewing the extra version-compatibility as something that only a library developer adds for his/her users (after testing).

The second issue is that it will be difficult to figure out what to load, if the goal is to load the best set of library. (You use library A that is compatible with MSL "3.2.1" and "3.3" and version "2" or "1" of library B where version "1" of library B is compatible with MSL "3.2.1" and "3.2", etc; yes - that is a straightforward graph-problem, of course, but currently it would require reading many files and if no good version is found we need to present this to the user.) If the goal is just to be able to send library "A" to someone that only has either MSL 3.2.1 or MSL 3.3 it is, obviously, easier to implement.

modelica-trac-importer commented 6 years ago

Modified by otter on 4 Jun 2013 16:14 UTC

modelica-trac-importer commented 6 years ago

Comment by hansolsson on 4 Jun 2013 16:41 UTC Conclusion:

modelica-trac-importer commented 6 years ago

Comment by dietmarw on 15 Nov 2013 13:30 UTC 80th Design Meeting is long over ... closing that milestone and still open tickets set back to *undecided*.

modelica-trac-importer commented 6 years ago

Comment by dietmarw on 16 Nov 2014 00:26 UTC Looking at MLS 3.3rev1 I could not find this being implemented.

modelica-trac-importer commented 6 years ago

Comment by dietmarw on 19 Dec 2014 07:01 UTC Ticket retargeted after milestone closed

modelica-trac-importer commented 6 years ago

Comment by dhedberg on 11 Mar 2016 10:43 UTC In SystemModeler we treat the case when a uses annotation contains several sub-entries with the same identifier as valid and that it means either version works.

Example: uses(Modelica(version = "3.2.1"), Modelica(version = "3.2.2"))

modelica-trac-importer commented 6 years ago

Comment by dietmarw on 11 Mar 2016 12:17 UTC So which version does SystemModeler choose if both versions of MSL are available (as in MODELICAPATH)?

modelica-trac-importer commented 6 years ago

Comment by dhedberg on 14 Mar 2016 08:49 UTC Hmmm, does it matter? Any of them will work. If one of the versions declared compatible is currently loaded, it will be used. Otherwise it is ultimately up to the user which one to load, but it would not matter.

modelica-trac-importer commented 6 years ago

Comment by sjoelund.se on 14 Mar 2016 08:53 UTC It comes back to comment:1 though. It's not a valid modification and it's desirable for tools that you could query the modifications to change them in a nice way. If you would set annotation uses.Modelica.version := "3.2.3", you don't really know what to do if you have the structure in comment:9.

modelica-trac-importer commented 6 years ago

Comment by dhedberg on 15 Mar 2016 07:45 UTC I guess you would have to query the user to know for sure. Has the user made changes so that his model is compatible with 3.2.3 only, or does it work for all 3.2.1 - 3.2.3? This seems like a tool issue which can certainly be solved. The problem with the uses annotation as of today is that it does not allow you to express that a model is compatible with two different versions of a library. I consider that to be a much bigger problem, and a limitation which we have been forced to work around by allowing multiple sub-entries with the same identifier as described.