High-level todo list

[Tobias-Fischer]

Hey @traversaro - thanks for all your work on RoboStack recently! Should we discuss what the remaining things are that need maintenance? As you can tell, I've got some "spare" time during the holidays.

Some remaining issues:

• repo independent:
  • [ ] use conda-forge pinnings: https://github.com/prefix-dev/rattler-build/discussions/1285 (@wolfv)
  • [ ] once all the work is done, write a blog post + social media
  • [ ] consider uploading to prefix.dev repo and change READMEs to reflect the new installation source
• ros-humble
  • [x] copy over .scripts from ros-jazzy and fix builds on main branch
  • [x] win-64 rebuilds
• ros-jazzy
  • [x] Add win-64 builds: https://github.com/RoboStack/ros-jazzy/issues/12 https://github.com/RoboStack/ros-jazzy/pull/14
  • [x] Add osx-64 and osx-arm64 builds: https://github.com/RoboStack/ros-jazzy/pull/5
• ros-noetic
  • [x] Switch over to rattler-build
  • [x] Rebuild linux-64
  • [x] Rebuild linux-aarch64
  • [x] Rebuild osx-64
  • [x] Rebuild osx-arm64
  • [x] Rebuild win-64

I probably missed quite a few - feel free to add @oursland @traversaro @wolfv @huweiATgithub

[traversaro]

Thanks for opening this! I am currently far from the laptop, but I have some win-64 related changes for ros-humble.

[Tobias-Fischer]

What do you think about adding run_exports to all packages with a tight pin (seeing we’ll have version information), and get rid off most run dependencies (except for Python and numpy)?

[traversaro]

What do you think about adding run_exports to all packages with a tight pin (seeing we’ll have version information), and get rid off most run dependencies (except for Python and numpy)?

I think it make sense, this would permit to stop adding depend dependencies as run dependencies automatically, but I think we should still add exec_depend dependencies as run dependencies.

[traversaro]

We also need to update docs to point users interested in jazzy to use robostack-jazzy instead of robostack-staging. fyi @xela-95

[Tobias-Fischer]

We also need to update docs to point users interested in jazzy to use robostack-jazzy instead of robostack-staging. fyi @xela-95

Done in https://github.com/RoboStack/robostack.github.io/commit/d3b9da848c74916d474638b4d5961c9af356ec94

[traversaro]

We also need to update docs to point users interested in jazzy to use robostack-jazzy instead of robostack-staging. fyi @xela-95

Done in https://github.com/RoboStack/robostack.github.io/commit/d3b9da848c74916d474638b4d5961c9af356ec94

Small fix in https://github.com/RoboStack/robostack.github.io/commit/8ad52f01de32859bc434a77438b0ce17c19f2d87 .

[Tobias-Fischer]

@wolfv - do you see any advantage in uploading to a prefix.dev repo instead of anaconda.org? If so, could you please open a sample PR that does that in one of the repositories?

[traversaro]

@wolfv - do you see any advantage in uploading to a prefix.dev repo instead of anaconda.org? If so, could you please open a sample PR that does that in one of the repositories?

Personally I would really prefer to continue (at least in tandem) to upload also to anaconda.org. The reason is that conda create -n conda-forge -n robostack-jazzy is much easier to remember and type rather then conda create -n conda-forge -n https://repo.prefix.dev/robostack-jazzy. At the moment the robostack, robostack-staging and robostack-humble channels are automatically mirrored over to prefix.dev, perhaps we should ask prefix to also mirror robostack-jazzy ?

[traversaro]

If so, could you please open a sample PR that does that in one of the repositories?

FYI in the robotology channel we upload to both prefix.dev and anaconda.org, and this is the code snippet we use: https://github.com/robotology/robotology-superbuild/blob/6f38a8c262d332cf3e9844cf6455729f16add446/.github/workflows/generate-conda-packages.yaml#L234-L241 .

[traversaro]

use conda-forge pinnings: https://github.com/prefix-dev/rattler-build/discussions/1285 (@wolfv)

The support for using directly the conda-forge-pinning file was fixed in rattler-build in https://github.com/prefix-dev/rattler-build/pull/1334 ( thanks @wolfv !). However, at this point I would add the full file from conda-forge-pinning in the next rebuild, as I am afraid of pinning some package current in migration to an older version w.r.t. to the version used to build the rest of the packages.

consider uploading to prefix.dev repo and change READMEs to reflect the new installation source

I think that specifying the channels with urls instead of simple names complexify a bit the installation process, so I would wait to see if https://github.com/conda/ceps/pull/91 progress before switching to only use prefix.dev to host packages.

[baszalmstra]

do you see any advantage in uploading to a prefix.dev repo instead of anaconda.org? If so, could you please open a sample PR that does that in one of the repositories?

I just stumbled upon this issue. There are a few advantages of uploading to prefix.dev: every channel on prefix.dev is served through a CDN, the CDN sync is only a couple of seconds, and you can upload packages without an API key through trusted publishing. All channels on prefix.dev can also serve repodata as "sharded repodata", which is significantly faster than the alternative. This mostly applies to large channels but I think robostack falls under that category. At the moment, though, pixi is the only client that supports this, but given that the conda community has accepted it, I assume this will roll out to other clients over time as well.

We are also still adding features to https://prefix.dev. Especially upcoming features in the area of supply chain security might be of interest to you.

Most of these features are also available when we just mirror the channels (we are also mirroring robostack-jazzy these days), but with supply chain security features we probably won't have them when mirroring. Regardless, and heavily biased, I think it would make sense to advertise the option for people to use the prefix channels, especially if they also use pixi!

Btw, you don't need to repo subdomain. You can just use https://prefix.dev/robostack-jazzy.

[traversaro]

Most of these features are also available when we just mirror the channels (we are also mirroring robostack-jazzy these days), but with supply chain security features we probably won't have them when mirroring.

In that case could it make sense to dual update to anaconda.org and prefix.dev, instead of relying on prefix.dev mirroring? I would not be enthusiastic of just uploading to prefix.dev as we would lose the really convenient feature of being able to do conda create -n env -c conda-forge -c robostack-jazzy ros-jazzy-desktop instead of relying on the less user friendly full URL. This may also be fixed by https://github.com/conda/ceps/pull/91 but I do not know when (or if) that proposal may be implemented.

Regardless, and heavily biased, I think it would make sense to advertise the option for people to use the prefix channels, especially if they also use pixi!

Sure, see also https://github.com/RoboStack/robostack.github.io/issues/67 that is kind of related. I do not know how to write "PRs are welcome" without the risk of sounding a bit passive aggressive, but I think any PR directed on updating the docs to show also how to use pixi with robostack (even by cross linking pixi docs) is welcome. Personally as I work with a lot of people that still use and are familiar with conda/mamba instead of pixi, I would strongly prefer to also keep the documentation on how to use conda instead of replacing it altogether with the pixi one. I think that the division between "Project-based workflows" and "Environment-based workflows" in scipy docs is a good example: https://scipy.org/install/ .