Support for version number of a library

[dietmarw]

I noticed that as of 0.8.0 impact installs all libraries in a folder without version number. The thing is that I know that users would like to have several versions of one library installed, side by side (at least the Buildings library developer asked explicitly for this (right @mwetter ?). So this is a feature that we should support.

[xogeny]

I did this deliberately. Let me explain. The use of version numbers in the names of Modelica packages (e.g., Buildings 1.5) is, in some sense, a poor man's package management scheme. It allows you to keep multiple versions around. For impact, my feeling is that it's job is to populate a directory with only the libraries that are immediately needed. It is not a "library storage" solution. It's job is simply to extract the needed ones for a particular analysis.

Perhaps @mwetter has some use case that I haven't considered. So I'd be interested in hearing about it. But my general feeling is that libraries should be stored on GitHub (etc) and that impact should only install one version of any given library since that is all that a tool could read in anyway.

[mwetter]

@xogeny : Having multiple libraries installed makes sense if one works on two projects, one uses Buildings 1.6 and the other uses Buildings 2.0.0. Having to pull down the whole library from github each time one switches seems in my view not necessary (and assumes that one has a decent speed internet connection). For example, Buildings 2.0.0 is 110 MB large, of which maybe 40 MB could be removed if we delete certain source files and reference results that are not needed.

In my case, I have all versions of Buildings installed on "/usr/local/Modelica/Library/Buildings x.y" so that I can run issues reported by users and test them with the respective release.

[xogeny]

Michael,

You say "if one works on two projects". But in that case, why not simply create two different directories to work in and have different sets of libraries in both? Is there some issue with that?

Also, I want to clarify a few other details. First, you wouldn't be checking things out all the time. You'd basically just install the libraries once in each directory. Then you'd be done. That being said, the features I am proposing in #97 would keep track of what versions you were currently using and if you wanted to change that, you could simply edit that file or re-install newer versions from the command line and the project file would get updated. Also part of #97 would be the ability to identify that you wanted to work on development of one or more libraries. In this case, impact would actually check out the library for you and establish a repository for that library. This would also be reflected in the project file so that if others came along and worked on the project, they could install all 3rd party libraries and checkout any development libraries all with a single impact install invocation.

That is what I had in mind. Feel free to comment on ways that might be unsuitable for your use cases.

[mwetter]

@xogeny Your solution works, but in my view, it would be more elegant to allow installing libraries with their version numbers in a directory such as /usr/lib/local/Modelica/Libraries. Then, if a user uses a library that uses, say, uses(Buildings(version="1.6")) and it is not found on MODELICAPATH (which may point to /usr/lib/local/Modelica/Libraries then impact would install the library, but not in the project folder.

What I don't like about having to install the library in my project folder (I assume this is what you propose) is that I put most of my projects on a version control system. In this situation, I would also put all the required libraries on that version control system (or having to update .gitignore, which is in my view not needed. I think if an official release of a library is used, this should be installed somewhere else than the project. You also wouldn't install /usr/lib/python2.7 in a project folder.

[xogeny]

@mwetter I guess one thing to be clear about is that at the design meeting in Lyon there seemed to be a general consensus among users (including Martin Otter) that MODELICAPATH is not a good solution in many cases. With impact, we've tried to turn things on their head. Instead of having a path from which the tool assembles the dependencies, we are creating impact to search across (generally networked) repositories to assemble all the required files in one directory. In a sense, you can think of impact of doing an a priori search of the "path" (which in our case is a complete index of Modelica libraries, not just libraries on your computer) and building the necessary directory structure for you. Of course, you can always use MODELICAPATH instead. We don't prevent that. I just think it would be awkward to mix the two.

As to your second point about version control, I don't think you ever have to worry that I'll build something that makes version control difficult. I think version control is essential. So much so, that we have a whole milestone for impact related to version control functionality. Let me share a few of those plans with you so you understand our goals.

You correctly point out that if you are working in a directory that is version controlled, you should not version control the libraries that you are checking out. This exact point is the basis for #87. But even beyond that, if you plan on changing the libraries, you want the ability to clone/checkout the libraries so you can work on them. That is what the "submodule" comment is about in #87. The point is that the project file discussed in #97 would allow you to describe exactly what you wanted "assembled" in your project directory. It might be published (static) releases of some libraries and checked out version of others for editing.

You are correct that you wouldn't install /usrlib/python2.7 in a project folder. But this is different. These are not standard libraries (generally speaking). Furthermore, look at all the trouble the Python community has with globally installed libraries. This is exactly one of the issues that people brought up at the Lyon meeting and exactly why most Python developers I know (including myself) use virtual environments for any development work. It is also why tools like npm (a package manager for Node.js) has the default behavior of installing things only locally, not globally (it is an option, just not the default). Furthermore, npm deals with the issue of "I don't want 50 copies of the same library in different directories all over my system" by giving users the option to link to a single master copy stored only once but symbolically linked to each project directory (on platforms that support this).

So we have considered these points quite a bit. I admit that this approach is perhaps a bit "opinionated" and doesn't give people all the flexibility they might expect. But we really are trying to follow best practices learned from several different package management solutions.