next release?

[syntron]

Is a new release of the OMPython package planned? The last release mentioned on github is v3.5.2 (2024/06/24) and 3.6.0 is available via pip (2024/07/12). However, the later version cannot be found on github; there is also no tag for this version.

[adeas31]

@arun3688 seems you forgot to tag 3.6.0 and only pushed it to pip.

@syntron yes a new release is planned since a lot of changes are done. Lets just wait until #249 and some other useful PRs are merged.

[syntron]

@adeas31: sounds good - no problem to wait

I have some additional changes in the pipeline - mainly some cleanup of the files:

• move classes from init.py into separate files (=> OMCSession; ModelicaSystem)
• move OMParser/init.py into just a directory

Reason:

• separate the differnet classes / parser such that specific commits touch only the corresponding file
• use init.py only for the package related definitions (public interface of the package)

I will check if I can prepare a PR for this

[ondras12345]

I also have some changes ready that are waiting for #249 to be merged (otherwise there will be conflicts):

• Fix two spaces in simflags causing error
• Do not ignore subprocess returncode

I would also like to look into refactoring createCSVData and cleaning up the docstrings, but I'm not sure if I'll be able to do that in time for the release.

Edit: also, I would like to make linearize() return x0 and u0 (and all the other values, too). I'll have to think about how to do that without breaking backwards compatibility. I'll probably have to add a new function that returns a dataclass instead of a tuple.

[adeas31]

@syntron @ondras12345 do you guys want to make more changes before we make a new release? Otherwise we can go for 3.7.0 soon.

[syntron]

@adeas31 I have two PRs open which are ready for merge: PR #294 (just updated) and PR #297 (new; small cleanups)

PR #295 is something for later as I have to build up the capability to test OpenModelica in docker first; the non-docker part is working well ;-)

[ondras12345]

I don't have anything ready.
#289 is just a tool for developers, so we don't care about releases.
I would like to tackle #260 at some point, but that can easily wait for a later release. I'm currently busy with university exams.

[adeas31]

I was thinking about the next release version number. Perhaps we can bump the major version number and make 4.0.0 instead of 3.7.0. The changes are quite significant. @arun3688 what do you think?

[arun3688]

@adeas31 Yes we can make 4.0.0 and that looks good

[ondras12345]

This changes the situation a bit. The solution to #260 would also be a significant, backwards incompatible change. If we are already making a major release, it might be a good idea to include it. I think I could prepare a pull request today. What do you think?

[ondras12345]

One more thing I noticed: if we are already making backwards incompatible changes, maybe we could also modify getter behavior a little.
Currently, most getters allow 3 uses:

>>> getValues()  # gets everything in a dict
{ "name1": value_1, "name2": value_2, "name3": value_3 }
>>> getValues(["name1", "name2"])  # gets multiple values in a list
[ value_1, value_2 ]
>>> getValues("name1")  # why does this return a single-element list?
[ value_1 ]

I find the third option rather weird. Why return a list with a single element in it? Clearly, the user is only interested in value_1. Why don't we return it directly?

[ondras12345]

Another idea: currently, there we are exposing internal functions that probably shouldn't be part of the public API. For example, I see no reason why the user would need to call ModelicaSystem.xmlparse() directly. Maybe these functions should be renamed to start with an underscore (e.g. _xmlparse()). While this does not prevent outside users from calling the function, it is a generally understood to mean that the function should only be used internally.

[syntron]

@ondras12345 Besides functions this would also help to define the scope for variables