-
Notifications
You must be signed in to change notification settings - Fork 43
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
Next generation of rosdistro tooling? #146
Comments
👍
I don't think that is feasible in a lot of cases where a generic Python package like this is released into for all platforms targeted by actively supported ROS distros. That would only be possible for a new tool which only offers Python 3 compatibility from day one (or all Python 2 platforms are aged out of support which would be ROS Melodic in 2023).
That sounds interesting. For some use cases like releasing packages with
Do you have examples for what you would imagine this to be used for?
While I agree with you that the current system is aging and it would be good to work towards the next generation of this infrastructure I doubt that there is much resources available for such a push. |
We no longer use Bloom, so that wouldn't be a primary consideration for an effort of this kind that we were spear-heading. When the time came, the interested parties would have to see about the effort involved in bringing the missing information to
Well, I stated a few in the paragraph you quoted. :) But since that was written, you guys have also gone through the whole process again with REP 154 and the addition of In any case, it sounds like in the short term if we want to pursue this, we should do so by kicking off a new toolset with a new name, and in a few years when Melodic is done, we can look at what we have and see if it's something which would be of interest to the community to adopt. |
Since the upcoming Noetic release is the last promised ROS 1 distro I doubt that anyone will spend effort on changing such an essential part for ROS 1 after that release is already out for that long. And if your only focus is ROS 2 you don't have to consider Python 2 anyway. |
Not sure if there's a better place to be having this discussion, but there are a few ways in which
python-rosdistro
is starting to get pretty creaky for us. Rather than hacking around its limitations or building a bunch of proprietary parallel infrastructure, we're wondering if there would be any enthusiasm for a more ambitious project to replace it. Some particular goals would be:manifest.xml
, and anything else pre-Groovy. None of this stuff has been relevant in years, and is probably rotted anyway.package.xml
file, by reusing the plugin infrastructure that's currently part of colcon. This would mean caching serialized PackageDescriptor instances rather thanpackage.xml
contents as strings.test_pull_requests
without needing a new REP.Several of these ideas address pain points that there are other open tickets for, such as #77, #82, and ros-infrastructure/rosinstall_generator#33.
I believe everything proposed here could be done without actually changing anything about REPs 137, 141, or 143, and it's even conceivable that the existing interfaces exposed by
rosdistro
could be maintained, such that tools like ros_buildfarm, rosinstall_generator, and others would require only minimal porting.The text was updated successfully, but these errors were encountered: