MSL 4.0.0, package management and new features #2974
Comments
christiankral
added
the
discussion
|
@christiankral I see your concerns. But for MSL v4.0.0 we already discussed and decided the scope of its changes in many meetings. You can find the meeting minutes in
I consider that feature list not as complete. If you have the urgent desire to add new basic features, you can of course propose to add them now. But as you see, we already have a rather ambitious roadmap and a tight schedule, which I am not sure if we can manage at all, given the resources we face. Therefore, I would like you to concentrate on the already assigned tasks and not to open any new topics for MSL v4.0.0:
Thanks! |
|
@christiankral I'd like to address your questions regarding impact. Impact has been developed as a test implementation to demonstrate what is possible. Similar approaches haven been done by other software projects, including Julia. So solutions are out there but the critical point is adoption. So far both Mike and I have had minimal response from tool vendors as to further develop a package management solution in the open and in a standardized way. Of course we could come up with yet another implementation, either using Julia's approach or similar one (node has a nice solution too). But all is in vain as long as nobody is interested in supporting it. Hence it would be premature to actually modularise the libraries right now but nothing stands against cleaning up the structure and the dependencies in order to make later modularisation possible. It really is frustrating to see that people like to use the MSL as their "one place to put all their applications into" just because Modelica is still one of the few languages that does not come with a package manager. And it is a very poor excuse too.
No, since it would be too premature. We first need a working and supported/accepted way to manage packages. So far the reaction as mentioned above was not very overwhelming (for whatever reason). Also see the issues we first need to address that @beutlich has pointed out and what we agreed on in MAP-LIB. It does not have to be another 10 years before we can have conversion but then again we currently have only one tool that supports conversion scripts. This is probably an issue that needs even higher priority in fixing.
A first step forward (and can already be done) would be to encapsulate the different sub-packages that are managed by the different library officers. This would not change any of the current functionality but would at least make it very visible to the developer how much they are trespassing into other sublibraries which really should not be the case (except for examples and interfaces). And thus help cleaning up their own libraries.
There are many and I don't care if impact would be a wrapper for a julia based package manager or a npm like solution or something entirely different. Any working and, again, supported solution would be better than what we have now, i.e., nothing. Just to visualise as to how involved the issue is. What you @christiankral are asking to get solved for MSL 4.0.0 is dependent on resolving at least the following language issues:
And even if all this would be resolved for the Specification 3.5 (which I doubt is realistic) it would still mean it can be implemented in a MSL after 4.0.0 (which is based on MLS 3.4). |
|
@beutlich and @dietmarw: Thanks for replying to my questions. My intention when writing this ticket was to get a better understanding on what the actual status of the planned package management is and what implications it on the MSL 4.0.0 development process has. From your conclusions I learn that there are way too many open issues and questions to get a package management system implemented before releasing MSL 4.0.0. It seems we need a project. One greater goal could be to have a common open source implementation of a package management system that can be used equally by all tool vendors. This then requires:
Possibly the 100th Modelica Design Meeting is a good opportunity to discuss these issues. |
|
My only comment here is that every modern language I can think of comes, out of the box, with a package manager. The current emphasis on having your code in the standard library is primarily driven by the fact that the standard library is sure to be installed on all machines. There are, in my view, a few pre-requisites to creating a package manager that we'd need to address first:
The problem I see here is that the ecosystem could be bigger and stronger with package management. But there isn't a strong enough impetus for doing this, which is unfortunate. |
There will not be a dedicated MAP-Lib session at the 100th MD meeting. |
|
@christiankral Can we close this issue then? |
|
I still see the need for a package manager and do not understand why we have closed this issue. Currently - at least in my company - Modelica-tools are "exotic" in terms of number of users compared to other tools. We as MA do not yet make good advantage of the "Modelica eco-system" with a huge number academic institutes, individuals and companies providing Modelica libraries. MA should provide an infrastructure for accessing this libraries and perhaps some quality assurance measures. Tool vendors should support this effort in their own interest. |
|
This issue was closed since we only focused on the upcoming MSL v4.0.0 milestone (in roughly six months) where it simply is not feasible. But the general issue is not forgotten at all. See #2974 (comment) and the 7+ issue links mentioned there. |
MSL 4.0.0 allows conversion scripts. This gives us the opportunity to think about the restructuring of the MSL in a greater way. I think we should therefore use this opportunity to improve the MSL. Otherwise it may take another ten or 20 years before the next chance comes along.
In some previous discussions there have been objections on getting new features / libraries into the MSL. From my understanding the arguments against providing new features / libraries was the missing degree of modularization and the missing package management system which should come first, before providing such new features / libraries. Is my understanding correct here?
So I wonder what is missing to make the next step in order to allow new features and libraries inside or outside the MSL?
As I understand, impact was planned to provide a package management system for Modelica. Possibly @mtiller, @dietmarw and others can answer and comment on some my questions here:
I would like to focus on possible solutions which allow us moving forward. I understand that a package (library) management is definitely required to better distribute library updates and additional Modelica libraries to all the Modelica users.
The text was updated successfully, but these errors were encountered: