Hello,
We’ve been discussing a bit during the Orekit day about incorporating Rugged in the distribution of Orekit in Python.
Something like what’s already done with Hipparchus.
The idea would be to have hipparchus + orekit + rugged loaded when calling import orekit from the Python console.
@petrus.hyvonen if I remember well you said that it would not be too hard to do.
Do you still agree with that ?
I was thinking - if it’s doable - that it would be a good idea to add Rugged 2.0 within the release of Orekit 10.0.
Is anyone here thinking the same ?
Cheers,
Maxime
Hi,
Yes I think this could be interesting.There are two steps basically in this, the first is just to include the library which should in principle be pretty straight forward (until you find out what are the real issues 
). The next step is to create PythonWrapperClasses for each of the class that needs subclassing in python. This is bit more handcraft work. Is the Rugged API using subclassing alot?
I can confirm that Rugged can be included as experimental in 10.0. I have used the mvn 2.1 Rugged version (no PythonWrappers)
It builds and some basic stuff that I can test seems to run.
Regards
Hi,
As mentioned during the Orekit Day, I am very interested in using Rugged in Python too. I would be happy to contribute, but I am not sure about my availability until September.
Cheers
Clément
Hi,
Thank you @petrus.hyvonen for testing it !!
And thank you @yzokras for proposing your help!
We talked a bit about this with Luc yesterday and he told me there were not many interfaces in Rugged, compared to Orekit at least.
Looking more in depth, I’ve found 11 interfaces and 4 abstract classes.
Is that what you were looking for when referring to “subclassing” ?
I can try to help too.
Hi Maxime,
Yes these are the classes and it looks quite limited number, this can be quite quickly implemented.
My thinking is to include the rugged in the same python module as orekit, the classes will then transparently be available at org.orekit.rugged
I am not completely sure about how to organize the PythonWrapper classes in this case. The package for rugged is org.orekit.rugged so the corresponding python wrappers could maybe be placed in org.orekit.python but it starts to be a bit mixed up. Alternative
I started to think that maybe we should transition to have the PythonWrapper classes in the same package as the original classes in order to have separation, but not sure. Any thoughts?
I withdrawn my previous post because I looked on the forge and understood what you meant 
I think it is a good idea to reproduce the original package organization into the PythonWrapper classes. Currently there are 110 classes in org.orekit.python so it is indeed starting to be a bit mixed up.
It will however introduce a big change for orekit users and will break former code, even if it is just a package organization change.
Maybe if we communicate enough about it the problem will be minor.
@yzokras what do you think ? In your case would it break a lot of your code and imply a lot of work ?
Would it break users’ code? These PythonWrapper Java classes are not called directly.
Hi,
Note: the PythonWrapper classes are only needed when you need to subclass a java class in python. Normal usage can access the orekit classes directly.
Indeed it is quite seldom that the the PythonWrapper classes are needed in standard usage it is really for advanced work or prototyping, the event stuff is maybe the most used but it is in normal cases not needed. But moving them completely could break some python code.
I haven’t tried but I think it is possible to have the classes both at the python package and at the “normal” package during a transition phase (like during version 10). This would be my preferred solution.
I agree with your solution Petrus.