Comments (5)
Thanks for filing this.
My first question, and I think the hardest problem to solve here, is where the "data" resides. Some thoughts:
- Create a separate registry similar to mixins. I don't like this because it introduces a discrete "source" for the data.
- Leverage
dnf
and/orapt
to query for the information we want.
a. We could look for packages providing.../colcon-.*/verb/foo.py
. This is only a heuristic though, and relies on conventions.
b. We could introduce a new tag to the deb and RPM packages, something likeProvides3: colcon-verb(foo)
. This would reside in thestdeb.py
. Still not ideal, but better than a separate repository.
from colcon-core.
2. We could look for packages providing
.../colcon-.*/verb/foo.py
if I understand you correctly, this would also only work for packages already installed, unless it'd use something like apt-file
(which has its own drawbacks).
from colcon-core.
this would also only work for packages already installed
Ah, I think you're right.
from colcon-core.
I think that option 1 would mirror the way that colcon-mixin and colcon-metadata work and would actually a pretty reasonable pattern for an extension registry of some kind.
My concerns with option 2 are that only works with system-wide installations of colcon and we'd have to explicitly add support for each packaging system (apt and dnf/rpm for sure but also pacman, zypper, apk, etc to to mention PyPI) which either creates a large maintenance surface or a very narrow scope of support for who can use the discoverability.
- While there are advantages to creating a self-declared system so that the colcon core team can remain hands-off, I think a counterweight to a self-declared system is the potential for abuse. If colcon in its default configuration is going to be suggesting or enabling discovery of additional extensions I don't think we can justify including packages with zero review unless we add a disclaimer so emphatic it discourages normal use of the feature
A further advantage of a core team maintained extension registry is that it further reduces the need to maintain all extensions within the colcon org on GitHub if that's a policy that we wish to relax.
from colcon-core.
One potentially interesting vector from a ROS perspective would be the ability to recommend colcon extensions that bring support for additional package package.xml build_type
s.
An example use case: if I have colcon-common-extensions plus our theoretical discovery extension installed and I try to build a workspace with ROS packages which have the build_type meson
or ament_meson
then colcon could suggest installing the colcon-meson
package.
Since package detection and discovery is handled in extensions it would be quite difficult for a non-ROS workspace to make build type recommendations without re-implementing some discovery locally which I think would be a misfeature.
See colcon/colcon-common-extensions#17
from colcon-core.
Related Issues (20)
- startup time is slow HOT 1
- DeprecationWarning: pkg_resources is deprecated as an API HOT 4
- Deprecation warning on Iron Tutorial Party: TypeCollectorDecorator SuppressTypeConversions HOT 14
- Missing option to specify log path HOT 2
- Builds with ament_python broken with sphinx >= 7.0.0 HOT 2
- Question: how to pass python parameters HOT 1
- Colcon build -> env: Argument list too long HOT 2
- [Question] colcon list slow ? HOT 2
- Building helloworld package fails HOT 4
- colcon-core 0.13.1python3.8 dependency breaks ROS 2 Dashing HOT 5
- Could not find a shell extension for the command environment HOT 4
- Wildcards in .dsv files
- ERROR:colcon.colcon_core* is declared multiple times HOT 2
- Colcon build silent package.xml parse errors
- `colcon build` uses the wrong Python version when inside a virtualenvironment on Windows HOT 2
- [bug] additional cmake args after CMAKE_TOOLCHAIN_FILE will clear it HOT 2
- Cache get_extension_points output
- empy version incompatibility HOT 4
- [Question] Correct way to build a ros driver which depends on a library without having to run 'sudo make install' on the library. HOT 6
- Design intent of setup.sh vs setup.bash HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from colcon-core.