You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is a while I have this in the back of my mind. For long time now, the pure-Python gym-ignition package and the hybrid C++/Python ScenarIO package are completely independent and can happily live in different repositories. However, from the maintenance point of view, this did not and does not really work well for us.
Another option is having two different setup.py files, one for gym-ignition and another for scenario. After all, the existing gym-ignition package already installs these two folders inside site-package, and it is not a really common pattern.
From the users point of view, nothing really change. The after-split gym-ignition package will depend on the new scenario package, and if anyone from downstream that has gym-ignition in their setup.py file, they will transitively get also the new scenario package.
From our point of view, instead, we should only do minor modifications to our CI/CD pipeline.
From the superbuild point of view (cc @traversaro) there's nothing to change. The CMake project will not be touched.
The text was updated successfully, but these errors were encountered:
diegoferigo
changed the title
Split setuptools packaging of gym-ignition and scenario
Split setuptools packaging of gym-ignition and scenarioMay 6, 2021
It is a while I have this in the back of my mind. For long time now, the pure-Python
gym-ignition
package and the hybrid C++/Python ScenarIO package are completely independent and can happily live in different repositories. However, from the maintenance point of view, this did not and does not really work well for us.Another option is having two different
setup.py
files, one forgym-ignition
and another forscenario
. After all, the existinggym-ignition
package already installs these two folders inside site-package, and it is not a really common pattern.From the users point of view, nothing really change. The after-split gym-ignition package will depend on the new scenario package, and if anyone from downstream that has gym-ignition in their setup.py file, they will transitively get also the new scenario package.
From our point of view, instead, we should only do minor modifications to our CI/CD pipeline.
From the superbuild point of view (cc @traversaro) there's nothing to change. The CMake project will not be touched.
The text was updated successfully, but these errors were encountered: