Open danielcranston opened 4 months ago
Personally I'd like to have such a capability, but it seems complicated. Related discussions https://github.com/ros-infrastructure/rosdep/issues/803 (and probably many more places).
More conversation in https://github.com/ros-infrastructure/rosdep/issues/325 (not just about Python pkg).
Alternative title: Not possible to restrict python packages to a specific version
Hi, thanks for making this awesome tool!
It would be really convenient if we could create rules that target python packages at specific versions.
Background
Imagine you have setup a custom rosdep source like this:
My understanding of rosdep is that the above
==1.4.0
is "illegal", and for a given rule (set of packages, in this case justtorch
), the idea is to offload the choice of package version to the package manager in question:apt
,pip
,npm
etc.For e.g.
apt
, this makes sense since apt packages are usually frozen for each ROS distro, and you canapt-mark hold
or edit/etc/apt/preferences.d
to restrict packages to certain versions.For
pip
otoh, it's not as simple because/etc/apt/preferences.d
for pip: the only way to pin a package is to specify it explicitly at install time or in somerequirements.txt
(which would only relate to a ROS package, not globally!)rosdep install
to respect themrequirements.txt
is not really tied into therosdep install
workflowSo apart from hosting and maintaining your own pip repository, it seems very tricky to restrict python package versions.
Rosdep rules specifying explicit package versions
One way around this would be to allow rosdep rules/keys (like the custom
torch-1.4.0-pip
above) to specify explicit versions. I imagine you guys would consider the rule valuetorch==1.4.0
to be unintended usage and "illegal", but I'm not sure since it does almost work out of the box:rosdep resolve
seems happyrosdep install
successfully installs at the specified version, but the post-install check for success (based on pip show) fails.System dependencies have not been satisfied: pip torch==1.4.0
(returns error code 1)rosdep check *package*
also fails for the same reason as above(For clarity, the issue is that rosdep invokes
pip show torch==1.4.0
, and "torch==1.4.0" is obviously not the name of an existing package)One way to overcome these issues is shown here: https://github.com/danielcranston/rosdep/commit/f11ed44c47c45819ae6e5cc2517b599e7df05b99. Essentially, we change
pip_detect
to consider the possibility of receiving a "explicitly versioned package" (including==
), and pass only the package name topip show
.Example of "best effort" of rosdep (expand me)
> Say one of your packages specifies these two rosdep rules: > * `python3-numpy`, that installs `numpy` version 1.17.4 via `apt` > * `python3-trimesh-pip`, that installs `trimesh` via `pip` (thus the latest version by default) > > Since a couple of weeks or months back, the latest version of `trimesh` requires a `numpy` version larger than 1.17.4, so `numpy` is upgraded to a higher version. > > So in conclusion, though the user most likely wanted/expected numpy 1.17.4, due to the "best effort"ness of rosdep this didn't happen.Questions
I'd be very grateful if you could answer the following questions:
requirements.txt
is not tied into therosdep install
workflow?constraints.txt
together with rosdep?Sorry for the long exposition, and thanks for reading!