Orekit Python Wrapper 13.0.1 Released

Dear all,

Orekit Python Wrapper for orekit 13 is now released, both in the “legacy” JCC wrapper and the new wrapper based on jpype. This includes all the updates in the 13.0.1 orekit java version - which is really substatial and with a great effort behind! See Orekit 13.0 released for that content. Again, many thanks for all the effort that went into this!

This Python release version does not contain Rugged as it is not yet ready for orekit 13.

orekit_jpype
For new projects I really recommend using the jpype version “orekit_jpype” - this is closest to the original java API, with no needs of casting, and has no modification to the java code. It has some limitations in not being able to subclass, but as interfaces are available this is usually just fine. This can be installed with normal pip (or uv that I would recommend!)

Included now in the source is also support for uv package manager in main as well as examples. That means one can with only uv installed and no other dependencies run “uv run jupyter lab” in the examples directory and get an notebook environment with some tests.

The released version is pinned to jpype1 version 1.5.0 - the last jpype releases has had some issues with the test framework that is being investigated.

orekit (JCC) version
As there is lots of new classes in orekit, there are lots of new Python wrapper classes. Sometimes it is not fully obvious which methods to expose to python for overriding so please post an issue if something is missing. The original java code at GitHub - petrushy/Orekit: This branch contain the java classes for orekit-python-wrapper is useful for understanding what to subclass.

One class, PythonAbstractRadiationForceModel, was troublesome to wrap and I have not found root cause, it is something in the relation to ForceModel that is not working in the automated code generation . This class has been omitted for now, but can be investigated if someone needs this class specifically.

Also on the JCC - the stubs which provides IDE docstrings is now depending on the jpype1 package. The stub generation depends on jpype1 and recent versions of generated stubs does also include jpype1 itself. jpype is not set as a dependency to Orekit JCC, so this should be installed by user if IDE hinting is needed.

This is likely the last major release version of Orekit JCC and for v14 we may transition fully to the jpype.

This is a major release, and some API will have changed so please be prepared that things will need modification for the update (don’t roll out in production directly…).

Again, many thanks for a great team and great work with Orekit!

6 Likes

Dear Petrus,

Many thanks for your impressive work tracking Orekit versions. Your Python wrappers are much appreciated and indubitably contribute to the wide adoption of Orekit.

I’m guessing that updating these wrappers takes up a lot of your time and energy. I wouldn’t want you to burn yourself out, so I’m wondering what’s the point of maintaining two Python wrappers, if one has several advantages over the other, both for you and for users?

Of course, I’m sure that people who chose the legacy wrapper when it was the only one available are happy to have effortless updates. But wouldn’t you consider announcing to the community that, from now on, only the new wrapper will be maintained and that people who want to have the wrapper for future Orekit versions will have to migrate their code? Are there any important points I’m missing?

Hi Sebastien,

Thanks for your kind words!

Yes the reason for having two wrappers is that I know the robustness of the “Classic” wrapper and have some systems running with it operationally. When we have clearly shown that the new wrapper is as stable (which everything points to) the Classic JCC version can be phased out. The amount of effort to maintain the jpype version for an upgrade is Significantly lower. This also leads to less “design” decisions on which methods to expose in subclassing etc, which I think helps in consistency.

Migration of code from Classic to new is straightforward.

It may be that we should depreciate this prior to 14.0.

1 Like

A new build (13.0.1.1) of the orekit_jpype wrapper has been put on pypi including the now updated Rugged library. Thanks @luc for the Rugged fixes!

1 Like