rosdistro

This repo maintains a lists of repositories for each ROS distribution

Explore on GitHub Read Hacker News discussions

2Distinct people

5Mentions

0Explicit recommenders

1.1KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

This repo maintains a lists of repositories for each ROS distribution

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year5 dated mentions

Observed mentions: 2016-09-13 22:00:31 UTC to 2021-05-21 01:13:42 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	1	1
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	0	0
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	0	0
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	0	0
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	2	2
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	2	2

What Hacker News says

5 sources

mikepurvis·May 21, 2021

The business about mapping from PyPI to system dependencies is an important one, and (having not read the entire thread) I do hope that gets some attention— it's particularly curious that it's been this long and it hasn't, given Python's often-role as a glue language. Another example of an ecosystem maintaining mappings out to system packages is ROS and rosdep: https://github.com/ros/rosdistro/blob/master/rosdep/base.yam... Now it's interesting because ROS is primarily concerned with supplying a sane build-from-source story, so much of what's in the rosdep "database" is the xxxx-dev packages, but in the case of wheels, it would be more about binary dependencies, and those are auto-discoverable with ldd, shlibdeps, and the like. In Debian (and I assume other distros), the binary so packages are literally the library soname + abi versions,

Read the rest

so if you have ldd output, you have the list of exactly what to install. Maybe one interesting "social" piece to including this kind of functionality would be what the behaviour of pip would become. Like, would it a) go back to needing to be invoked as root and call through to the system package manager, b) emit the command needed for the user to install the required system packages, or c) download the system packages itself, extract the libraries, and insert them into its non-root-owned virtualenv or whatever other environment?

In What to do about GPU packages on PyPI?

mikepurvis·Apr 9, 2021

Thanks for the response! > This is difficult to answer without knowing more details. The situation specifically is the ROS ecosystem, where metadata is managed in these package.xml files: https://github.com/ros2/rclcpp/blob/master/rclcpp/package.xm... The federated nature of the ecosystem has led to a culture where it's very normal to be building dozens of these at once, in the same workspace together, often from multiple repos (the repo above has four in it). So there are several build tools which automate the work of examining a source workspace and building all the packages within it in the correct topological order, in parallel, while respecting build_depend tags. The newest of these tools (colcon) has actually made the package.xml optional in many cases, as it can examine CMakelists, setup.py, BUILD, etc, and discover for itself what

Read the rest

the dependencies are. Your "distribution" of ROS is formed by listing all the packages and repos in this big file, for which there is other tooling to manage pulling dependency sources, whatever: https://github.com/ros/rosdistro/blob/master/foxy/distributi... Anyway, so the existing ROS/nix efforts (1) seem to basically consume all of this package/distribution metadata at once and generate a giant parallel structure of nix definitions (eg https://github.com/lopsided98/nix-ros-overlay/blob/master/di...), which I fear would be completely opaque to my users. And any system which required a flag day where everyone leaves behind these existing workflows would be an immediate non-starter. I think the ideal scenario (and what it would look like if I built this myself based on debs) would be that you could source the "base" workspace as usual (enter the nix-shell?), and check out source, build groups of packages as usual with colcon, but there'd be an extra plugin/verb/flag for it, which would make it build each package as a nix package instead of into the usual installspace. The verb would generate the nix definitions on the fly, and probably handle the invocation and build-parallelism side of it as well. [1]: https://github.com/acowley/ros2nix, https://github.com/lopsided98/nix-ros-overlay

In Nix is the ultimate DevOps toolkit

mikepurvis·Aug 20, 2020

I feel like there are scenarios where it's convenient to have a plain text string that is certain not to gum up parts of the system that would choke on punctuation or a leading digit (see for example this package-mapping yaml: https://github.com/ros/rosdistro/blob/master/rosdep/base.yam...). Of course, Fedora 19 is codenamed `schrödinger` including the unicode character, so that's been an interesting experiment in ensuring that all the systems which ingest and process the codenames can handle that. Anyway, the obvious thing is that a codename is more fun and memorable than a number; it's something to hang marketing and such off of. Presumably this is why MacOS versions have always had public codenames since 2002. But I think the practical reasons are valid as well.

In A deep dive into the official Docker image for Python

abinaya_codes·Jan 23, 2020

If you know basic python, checkout ROS, interesting issues to solve -> https://github.com/ros/rosdistro/contribute

In Browse good first issues to start contributing to open source

mikepurvis·Sep 13, 2016

Our use-case is perhaps a bit unique, but ROS has a federated development model, meaning literally hundreds of repos. See the following file which maps repos to package names and versions: https://github.com/ros/rosdistro/blob/master/indigo/distribu... These get generated into thousands of jobs: http://build.ros.org/view/All/ It would be totally unrealistic to rev job configurations by making commits into the individual repos (and in the public open source case, actually impossible— the maintainers of that community build infrastructure don't have write access to many of the repos— it's equivalent to a Debian distro using DSC files to grab tarballs).

In GitLab Master Plan