-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement a machinery to easily access model locations on C++ and Python #130
Implement a machinery to easily access model locations on C++ and Python #130
Conversation
bindings/CMakeLists.txt
Outdated
endif() | ||
file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/METADATA "") | ||
file(APPEND ${CMAKE_CURRENT_BINARY_DIR}/METADATA "Metadata-Version: 2.1${NEW_LINE}") | ||
file(APPEND ${CMAKE_CURRENT_BINARY_DIR}/METADATA "Name: icub_models${NEW_LINE}") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that for pep-0008 the use of underscore in package names is discouraged, see https://www.python.org/dev/peps/pep-0008/#package-and-module-names, while the underscore is actuall suggested for the module name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Double checking with @diegoferigo .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I interpret the PEP correctly, it states that the usage of underscores in module names is discouraged. Practically, if you cannot find a single name descriptive enough, this suggestion from a very old PEP is not really followed and you can find pretty often _
.
This being said, the module name is different from the package name, and this section of CMake code is about the resulting package name. In this case, it does not matter much, because underscores in the metadata are parsed as dashes by PyPI and pip. What differs is just the sdist / wheel package name. And I mean, a package with name icub-models
containing a module stored in folder icub_models
so that it can be imported as import icub_models
, when packaged, produces icub-models-....{zip|wheel}
. This bother mostly CI since you have to take care of two different names. Since packages named icub_models
can be installed with pip
as pip install icub-models
regardless, I'd suggest to keep all naming consistent, using always _
.
file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/INSTALLER "${ICUB_MODELS_PYTHON_PIP_METADATA_INSTALLER}${NEW_LINE}") | ||
install( | ||
FILES "${CMAKE_CURRENT_BINARY_DIR}/METADATA" "${CMAKE_CURRENT_BINARY_DIR}/INSTALLER" | ||
DESTINATION ${PYTHON_METADATA_PARENT_DIR}/icub_models-${PROJECT_VERSION}.dist-info) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that even if we call python package name icub-models
, the directory name here should use underscore, see conda-forge/opencv-feedstock#300 (comment) .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot @GiulioRomualdi ! My only doubt for what regards this implementation is that by itself is not relocatable. This is not a problem as long as we just distribute binaries via apt packages (as in that case the CMAKE_INSTALL_PREFIX used to install the binaries is always the same, i.e. /usr
or /opt/something
) or conda (as conda handles automatically strings in the binary packages to make them relocatable).
However, if we ever want to ship this via PyPI, this may be a problem. However, I do not think this should block the PR as in any case this is a great step forward, and if necessary I think it would be trivial to replace the pybind11 Python library with a native Python library for which handling the relocatability is trivial.
Hi @traversaro, I applied the suggestions you proposed. Before merging the PR I would like to highlight:
|
Devel is fine.
Yes, that would great otherwise people will never know of the feature! The README probably would need a revamp in general (see #90), but I think that for this feature I think it is ok to just add two sections after https://github.com/robotology/icub-models#use-the-models-with-gazebo, something like:
|
bindings/python/CMakeLists.txt
Outdated
|
||
# Output package is: | ||
# | ||
# bipedal_locomotion |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
# bipedal_locomotion | |
# icub_models |
bindings/CMakeLists.txt
Outdated
install(FILES "${ICUB_MODELS_PYTHON_PACKAGE}/__init__.py" | ||
DESTINATION ${PYTHON_INSTDIR}) | ||
|
||
# Install pip metadata files to ensure that blf installed via CMake is listed by pip list |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similarly to #130 (comment), the reference to blf
seems to be a leftover as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You got me
5cf0b9a
to
258ee6a
Compare
Co-authored-by: Silvio Traversaro <silvio@traversaro.it>
258ee6a
to
0744f7f
Compare
…aries to load the models
0744f7f
to
6da40e2
Compare
@traversaro I updated the README in 6da40e2 |
For me it is ok! Can you add a note in the CHANGELOG.md ? Thanks! |
Thanks! |
With this PR I want to propose a solution for the #91. In 3c869f1, I implemented a C++ library that will allow us to easily access the location of a model installed in by
icub-models
repo. The location of the files is automatically generated by acmake
machine that is in charge to set thepath
accordingly to the installation folder.I also implemented the python bindings (with pybind11) 8d7efc7. In theory, it would be possible to use swig to support more language. However, since I've never used it I've preferred to start with something simpler.
This is an python script where I used the module. I replicated the API suggested by @traversaro in #91 (comment)