rosdistro VS spack

I have added their rosdep names (found here) to my packages.xml (see the end of this post), but even after running catkin-make and trying to run the module, the script throws a ModuleNotFound exception at the UTM package meaning that the package was never installed.

I second this. Just remove the package by removing whatever you added to the rosdistro repo when submitting/publishing the package.

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, so if you have ldd output, you have the list of exactly what to install.

The names you use for the tag (and the other dependency tags in your package.xml) are used by rosdep to figure out what needs to be installed. The name doesn't necessarily correspond to the apt or pip package name, but most of the time it's the same. For example, for matplotlib: https://github.com/ros/rosdistro/blob/24141d9063fddd6eeca7f1db9e721fa8d600c62f/rosdep/python.yaml#L6296

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, 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 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 users and any system which required everyone to leave 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 packages as usual with colcon, the usual workspace-building tool, 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

Thanks for the feedback. I bumped a couple of the core devs and got the change reverted and it is now merged. It should be in the next Noetic release.

> Are we talking about the same autotools?

Yes. Instead of figuring out how to do something particular with every single software package, I can do a --with-foo or --without-bar or --prefix=/opt/baz-1.2.3, and be fairly confident that it will work the way I want.

Certainly with package managers or (FreeBSD) Ports a lot is taken care of behind the scenes, but the above would also help the package/port maintainers as well. Lately I've been using Spack for special-needs compiles, but maintainer ease also helps there, but there are still cases one a 'fully manual' compile is still done.

> Suffice it to say, I prefer to work with handwritten makefiles.

Having everyone 'roll their own' system would probably be worse, because any "mysteriously failure" then has to be debugged specially for each project.

Have you tried Spack?

* https://spack.io

* https://spack.readthedocs.io/en/latest/

Well, good luck with that, cause it's broken.

Previous release miscompiled Python [1]

Current release miscompiles bison [2]

[1] https://github.com/spack/spack/issues/38724

[2] https://github.com/spack/spack/issues/37172#issuecomment-181...

gh is available via Homebrew, MacPorts, Conda, Spack, Webi, and as a…

> I can't count the number of times I've seen people say "md5 is fine for use case xyz" where in some counterintuitive way it wasn't fine.

I can count many more times that people told me that md5 was "broken" for file verification when, in fact, it never has been.

My main gripe with the article is that it portrays the entire legal profession as "backwards" and "deeply negligent" when they're not actually doing anything unsafe -- or even likely to be unsafe. And "tech" knows better. Much of tech, it would seem, has no idea about the use cases and why one might be safe or not. They just know something's "broken" -- so, clearly, we should update.

> Just use a safe one, even if you think you "don't need it".

Here's me switching 5,700 or so hashes from md5 to sha256 in 2019: https://github.com/spack/spack/pull/13185

Did I need it? No. Am I "compliant"? Yes.

Really, though, the main tangible benefit was that it saved me having to respond to questions and uninformed criticism from people unnecessarily worried about md5 checksums.

[1] https://github.com/spack/spack/blob/develop/var/spack/repos/...

In Spack [1] we can express all these constraints for the dependency solver, and we also try to always re-cythonize sources. The latter is because bundled cythonized files are sometimes forward incompatible with Python, so it's better to just regenerate those with an up to date cython.

[1] https://github.com/spack/spack/

You want to look at the tools used for HPC systems, these are generally very well tried and tested and can be setup for single machine usage. Remote access - we use ssh, but web interfaces such as Open On Demand exist - https://openondemand.org/. For managing Jobs, Slurm is currently the most popular option - https://slurm.schedmd.com/documentation.html. For a module system (to load software and libraries per user), Spack is a great - https://spack.io/. You might also want to consider containerisation options, https://apptainer.org/ is a good option.

git clone https://github.com/spack/spack.git ./spack/bin/spack install gcc