Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Track packages that are released in ROS build farm but are/should be in conda-forge

Aberta
  • Algo errado?
#17 12 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
25/100
Tipo de issue
Funcionalidade
Clareza
Precisa de esclarecimento
Status de atividade
Estagnada
Stack de tecnologia
cmake, debian
Domínio
build-system, devops

Direção de pesquisa

Comece pela tabela de pacotes e pelas issues vinculadas de conda-forge, rosdistro e relacionadas; compare quais pacotes estão duplicados e se os pacotes de vendor adicionam arquivos. Considera-se concluído quando o projeto tiver uma forma documentada e sistemática de identificar os pacotes que deveriam usar conda-forge em vez de serem reconstruídos por meio do Bloom.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

The ROS Debian binary packages that are released via Bloom are essentially a distribution of software that builds on top of another distribution of software (the base Debian/Ubuntu repositories). This relation is similar to the one that in the conda world exists between conda-forge and bioconda channels, and in a sense is the same relation that we would like to create between conda-forge and robostack.

Over the time some packages that we not ROS-specific (i.e. they did not depend on the ROS communication middleware) were released with Bloom for several reasons. The major reason is that it was much faster and easier to get a package published via Bloom rather then by going through the actual Debian/Ubuntu packaging process, while in some other cases a package was indeed available in Debian/Ubuntu repos, but the version available in the repos was not recent enough, and it was not possible to update it due to Debian policies for updates in already released distros.

In the case of robostack, given that getting new packages in conda-forge is relatively easy and fast, and the same holds for updating the version of existing packages, I think it make sense to avoid to re-build packages that are or should be in conda-forge even if they are release in bloom/rosdistro, but rather we should have some systematic way to skip them and install the conda-forge version instead. I am not sure what is the proper way of doing so, but for the time being I opened this issue to track the occurrences of this pattern that I spot.

Package repo It is already in conda-forge? rosdistro package name Does the rosdistro package also adds some files? Related issue(s)
https://github.com/pybind/pybind11 https://github.com/conda-forge/pybind11-feedstock pybind11_catkin in ROS1, pybind11_vendor in ROS2 Yes https://github.com/RoboStack/ros-noetic/issues/19
https://github.com/OctoMap/octomap https://github.com/conda-forge/octomap-feedstock octomap No https://github.com/ros/rosdistro/issues/26527
https://github.com/flexible-collision-library/fcl https://github.com/conda-forge/fcl-feedstock fcl No https://github.com/ros/rosdistro/pull/27789
https://github.com/IntelRealSense/librealsense No librealsense No https://github.com/robotology/robotology-superbuild/issues/564
https://github.com/borglab/gtsam Yes gtsam No https://github.com/ros/rosdistro/pull/23198
https://github.com/ethz-adrl/ifopt No ifopt No
https://github.com/stack-of-tasks/pinocchio https://github.com/conda-forge/pinocchio-feedstock pinocchio No
https://github.com/oxfordcontrol/osqp Soon, https://github.com/conda-forge/staged-recipes/pull/13587 osqp_vendor Yes, the CMake config files for the osqp_vendor CMake package, and the osqp_vendor-extras.cmake file. See https://github.com/tier4/osqp_vendor
https://github.com/OGRECave/ogre https://github.com/conda-forge/ogre-feedstock rviz_ogre_vendor Yes, it also installs the CMake config files for the rviz_ogre_vendor CMake files, and some additional related files. Furthermore, just on Windows the used ogre also statically links a locally built copy of freetype and zlib.
https://github.com/stack-of-tasks/eigenpy Yes eigenpy No.
https://tvm.apache.org/ https://github.com/conda-forge/libtvm-feedstock tvm_vendor Yes, it even enables some options while compiling tvm, that are related to vulkan and spirv, that I am not sure if they are available in conda-forge.

Just for ROS2, there are a few more in https://github.com/ros2/?q=vendor .

Linguagem predominante
Astro
Estrelas
386
Forks
37
Merge médio
3h 38min
PRs com merge (30d)
15

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de RoboStack/robostack.github.io

Todas as issues de RoboStack/robostack.github.io

Issues semelhantes

Mais issues de Build System

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.