search

stack-of-tasks / pinocchio

A fast and flexible implementation of Rigid Body Dynamics algorithms and their analytical derivatives
http://stack-of-tasks.github.io/pinocchio/
BSD 2-Clause "Simplified" License
1.91k stars 395 forks source link

Wheel packaging #1317

Closed nim65s closed 3 years ago

nim65s commented 4 years ago

Hello,

I have a first draft of wheel packages for eigenpy-2.5.0 example-robot-data-3.6.1 hpp-fcl-1.6.0 and pinocchio-2.5.0.

They are available for python 2.7, 3.5, 3.6, 3.7, 3.8 and 3.9, and for the manylinux2014 platform (ie. most Linux distributions form 2014 or after)

All of this is on the test instance of PyPI, one can try (preferably in a virtualenv or a docker) with :

pip install -i https://test.pypi.org/simple example-robot-data

(which depends on pinocchio, which depends on hpp-fcl, which depends on eigenpy, which depends on numpy, so all of this will be installed at once).

After installing this, all python unit tests from pinocchio are OK.

This issue is just to discuss and track progress on the topic.

The first question is: should I upload those packages to the main PyPI instance, even if this is not bullet-proof / production-ready yet ?

Also, I have to mention that there is a limitation to those wheels: they must all be installed in the same site-packages, because otherwise, the dynamic link from eg. pinocchio_pywrap*.so to libeigenpy.so would not be resolved (unless the users start playing with LD_LIBRARY_PATH, so there are workarounds, but we shouldn't rely on that). The standard approach would be to embed a copy of libeigenpy.so both in the wheel distribution of eigenpy, of hpp-fcl, and of pinocchio. But this failed in some of my early tests. Maybe my tests were not correct, or maybe there are real issues with this duplication, eg. in Singleton handling.

wolfv commented 4 years ago

what is the main benefit over conda? (asking as a random bystander :)

cmastalli commented 4 years ago

The first question is: should I upload those packages to the main PyPI instance, even if this is not bullet-proof / production-ready yet ?

I can't help you with this issue. But it would be ideal that the user experience will be like installing any other pip library. For instance, it would be nice to only do:

 pip install --user pinocchio, crocoddyl

When you said "main PyPI instance", is this what do you mean?

jcarpent commented 4 years ago

@wolfv One short answer is that conda is not used by everybody (unfortunately, because it is a very convenient and efficient tool). And some people keep on asking to get access to Pinocchio via pip.

On the other side, it is a bit pitty that the conda-press project has stopped. Because, it would be a key feature, avoiding dupplications of packages and releasing systems.

jcarpent commented 4 years ago

Also, I have to mention that there is a limitation to those wheels: they must all be installed in the same site-packages, because otherwise, the dynamic link from eg. pinocchio_pywrap*.so to libeigenpy.so would not be resolved (unless the users start playing with LD_LIBRARY_PATH, so there are workarounds, but we shouldn't rely on that). The standard approach would be to embed a copy of libeigenpy.so both in the wheel distribution of eigenpy, of hpp-fcl, and of pinocchio. But this failed in some of my early tests. Maybe my tests were not correct, or maybe there are real issues with this duplication, eg. in Singleton handling.

The ideal stuff would be to rely on static libs for pip, to avoid clashes. This would be not so hard to do for eigenpy, hpp-fcl and pinocchio.

jcarpent commented 3 years ago

Any feedback on it?

nim65s commented 3 years ago

I'm super busy at the moment, sorry. There isn't much work left, and this is pretty high on my priority list, so this should be done by the end of the month.

nim65s commented 3 years ago

Hello,

eigenpy, hpp-fcl & pinocchio are available on PyPI (pinocchio under the pin shortcut, as "pinocchio" was not available).

They are build on the manylinux_2_24 platform, so they should work on any linux with a glibc >= 2.24, ie. Debian 9 stretch (currently "oldstable"), and everything more recent.

They are only available for the x86_64 architecture, but they could be built on some others (especially arm & arm64) if this is useful for some of our users.

In this first version, the wheels only provide the required things to use those packages, not to develop with them. There is still an on-going work to improve this.

PS: there is also TSID, crocoddyl & example-robot-data

jcarpent commented 3 years ago

Fantastic! Thanks a lot @nim65s.