-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
http_relay: 1.0.1-1 in 'noetic/distribution.yaml' [bloom] #37717
base: master
Are you sure you want to change the base?
Conversation
See my comments in #37716 (review) about this package. |
Reproducing the conversation from #37716 clalancette
peci1:
|
That is very surprising, but OK.
I think my big issue with adding this is that we aren't aiming to be a generic Linux distribution like Debian or Ubuntu. ROS distributions are more focused on robotics than that. While I agree that doing http proxying is sometimes useful and necessary in robotics, there is nothing robot-specific about it. There should be packages from the wider ecosystem that can do this for you. If something like this doesn't exist in PyPI.org, for instance, then I would suggest that this would be a contribution there. |
If they later want to release a package that depends on this code (say a |
Exactly. I agree it would make sense to try to push such a package into Ubuntu repos, but that is a much more far-fetched way then getting it via ROS buildfarm. So this ROS package is a kind of shortcut. But there's no way of getting the package to Ubuntu repos for Focal, so the ROS way is actually the only possible currently. |
I might suggest reading through https://wiki.debian.org/DebianMentorsFaq#Packaging - especially "How do I add a new package to the archive?". I don't think the process is so very long, and this would expand your reach beyond ROS distributions.
The ROS buildfarm is not "free" in the sense of requiring no resources to maintain - so I'd personally prefer if we avoided using it as a shortcut to properly releasing generically useful software. Anybody who wants the package may check it out as source, so they are not blocked from using it - and PyPI has no barrier to entry at all. |
I am usually the first person to encourage pushing dependencies further upstream and maintaining a tight focus in the ROS distributions on packages that either rely on ROS packages or are quite exclusively dependencies of ROS packages with little other utility. I don't disagree with any of the arguments toward pushing this functionality upstream. There are a couple of points of nuance I want to recognize: Putting packages in PyPI is of extremely limited utility if your ultimate goal is depending on it in an officially released ROS packageThe most immediate value I see for releasing a Python package to PyPI is that PyPI is the closest thing to a global registry for Python module names, thus being present in that registry makes it less likely to collide with another python package when submitting your package for inclusion in Debian/Ubuntu and Fedora/EPEL. For dependencies which are already on the path to being upstreamed, I think that these can be considered for vendoring in order to start building on them today. If there's a package that's in Debian Unstable or even an Intent-To-Package bug filed for it, and the package itself is not something that is already available on our target platforms but at a different version. I would consider allowing that to be included in a ROS distribution with the expectation that it will eventually be removed in favor of the upstream package. |
In this thread there's some words with wisdom that I want to see spread across the communities. I'm also afraid this sort of discussion keeps happening (may not be many times though). |
Thanks, I decided to go that way. I created pip package https://pypi.org/project/http-relay/ and now I'll try to make the ITP. I'll ping here when that's done to decide what to do with this proposed ROS package. |
The ITP is finished! https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050035 . I uploaded the built ubuntu packages to https://launchpad.net/~peci1/+archive/ubuntu/http-relay . Do you know of a Debian sponsor who might be interested? |
Great, thanks! Should I contact him or will he contact me? |
Could you please mail me (jrivero@osrf..) with the repository where you have the |
This PR hasn't been activity in 14 days. If you are still are interested in getting it merged please provide an update. Otherwise it will likely be closed by a rosdistro maintainer following our contributing policy. It's been labeled "stale" for visibility to the maintainers. If this label isn't appropriate, you can ask a maintainer to remove the label and add the 'persistent' label. |
This PR hasn't been activity in 14 days. If you are still are interested in getting it merged please provide an update. Otherwise it will likely be closed by a rosdistro maintainer following our contributing policy. It's been labeled "stale" for visibility to the maintainers. If this label isn't appropriate, you can ask a maintainer to remove the label and add the 'persistent' label. |
Thanks to @j-rivero the package has just been accepted to Debian unstable: https://packages.debian.org/sid/python3-http-relay . It got already pulled to noble-proposed: https://launchpad.net/ubuntu/+source/http-relay/2.1.3-1 . Now holding my breath whether it will make it into noble in time :) When that happens, I think we can move on with this PR? |
…m-http_relay-1 # Conflicts: # rosdep/python.yaml
0c78d08
to
9ae96a9
Compare
So, the package has landed in Noble! https://packages.ubuntu.com/noble/python3-http-relay . I've tried to update this PR according to the results of the previous discussion. However, I'm not sure I did it right and technically correct:
I'm not sure whether rosdep is clever enough to look for the key in rosdistro when it finds |
Or would it be better to do the release for older debian-based systems via reprepro? |
CC: @nuclearsandwich or @cottsay. Do you have any input on @peci1's current state? |
I did some local testing, and it appears that the rosdep database takes precedence over the ROS distribution index even when the rule is explicitly
EDIT: |
Uh-oh... thanks for the testing, @cottsay . So, would it be acceptable to change the behavior of rosdep? Or does anyone see a better approach? |
I haven't looked into this deeply, but I don't see any downside to deepening the "merge" so that the ROS package can satisfy the nulled rule for I don't think it will be trivial, though. We would need to handle |
I'll have a look at it next week. Although a new behavior, I think it is desirable to add it because what I try to do with this package is the recommended way of adding packages that will get upstreamed to distros but need to be released in ROS repos for older distros. |
Increasing version of package(s) in repository
http_relay
to1.0.1-1
:noetic/distribution.yaml
0.11.2
null
http_relay