Comments (7)
@ivanpauno Is the document naming/formatting okay for a PR as is? I can go set that up now if it looks like it's in good enough format for that discussion.
from launch.
I thought a little bit about this, and about how it would look in the new frontends (examples only in XML here).
I would have the following classes:
- A
Node
class, that describes a node (name, namespace, remappings, parameters).- A
ComposableNode
class. - A
LifecycleNode
class.
- A
- An
Executable
class (orProcess
class), that describes an executable (with process information).- A
SingleNodeExecutable
class that describes an executable that runs only one node. It may also inherit fromNode
, or take aNode
in its constructor (is an implementation detail). - A
MultiNodeExecutable
, which inherits from node and takes a list ofNode
in its constructor.
- A
- An abstract
BaseExecute
action.- An
Execute
action.- An
ExecuteContainer
action. It should take both aNode
, that is the container, and a list ofComposableNode
as arguments.
- An
- We could have
ExecuteRemotely
,ExecuteInDocker
, etc.
- An
For XML (or other frontend), I think we should check the parent entity and behave differently according to that.
e.g.:
<node ATTRIBUTES_FOR_EXECUTION_EXECUTABLE_AND_NODE_DESCRIPTION/>
<execute_remotely ATTRIBUTES_FOR EXECUTION>
<node ATTRIBUTES_FOR_EXECUTABLE_AND_NODE_DESCRIPTION/>
<multi_node ATTRIBUTES_FOR_EXECUTABLE>
<node ATTRIBUTES_FOR_DESCRIBING_A_NODE/>
<node ATTRIBUTES_FOR_DESCRIBING_A_NODE/>
</multi_node>
</execute_remotely>
So in each case the tag may accept different attributes, but it would be less verbose.
from launch.
I've been working with the guys who are putting together ideas for Multi-machine launching (ros2/design#255), and wanted to follow up on some of the feedback there. I saw the mention of this issue, and I'd like to see if we can help on getting some of this work done, and figure out how to use this concept for our remote execution needs. Also want to make sure we don't start running with ideas that have been obsoleted by other changes. There are good notes above from both @wjwwood and @ivanpauno; does everything here still feel current?
Also, there's discussion in the FP about some changes to how things would be called, for instance:
e.g.
Execute(Executable(...))
orExecute(Node(...))
rather thanExecuteProcess(...)
andNode(...)
Are there any concerns about breaking changes and backward compatibility in this area?
from launch.
Are there any concerns about breaking changes and backward compatibility in this area?
Yes. It should be done in a backwards compatible way. i.e.: The ExecuteProcess
class, etc, should still exist, making use of the new objects to avoid duplicated code, and print a deprecated warning when an user uses it.
I think that everything previously commented here still stands.
I think that a good start would be to propose an API, and share it for review.
In general, my idea is to separate descriptions from "Execute" actions. We've already done that in some cases (like here), but we haven't applied that consistently.
If you need any extra input for the design of the API, please let me know and I will try to help.
from launch.
@ivanpauno Finally had some time to dig into this and learn quite a bit more about how things are structured. I'm not sure if this is in quite the format you were wanting, but we've put together some thoughts about how to approach this. I've created a document in a fork of the design repo, but I'm not sure the document itself needs to be pulled there. Just needed a place to park some thoughts.
Take a look to see if things are on the right track; if you'd like me to move this somewhere else, I certainly can.
Also, (and this is probably a little premature) assuming we eventually get to the point of implementing the refactor, can you point me to the appropriate unit tests so I can make sure to update them/add new ones as appropriate?
ExecuteProcess Refactor discussion
from launch.
@roger-strain Thanks for working on this!
I had a quick look, here some comments:
- Probably,
launch_ros.descriptions.ComposableNode
can't inherit fromlaunch_ros.descriptions.Node
, as it doesn't have for example anode_executable
argument. Maybe both can inherit from a common base class, that doesn't specify either plugin name nor executable name. Maybe, we don't need a base class at all. - About the
apply_context
idea. I think that probably people would want to have both kind of substitutions, e.g.: for some things check an environment variable locally, from some others check an environment variable in the remote computer. I would rather have another set of substitutions for the ones that have to be executed in the remote computer, e.g.:launch.substitutions.remote.EnvironmentVariableSubstitution
. We could add some magic to infer theconnection_description
if theSubstitution
is composed in aExecuteSshProcess
action, to avoid duplication (I have a mental idea of how to do that).
I think that before continuing the discussion, it would be good to open a PR in ros2/design
.
It will have more visibility there, and it's also better for receiving feedback (making comments right after the place it applies is nicer).
from launch.
This issue has been mentioned on ROS Discourse. There might be relevant details there:
https://discourse.ros.org/t/ros-2-tsc-meeting-minutes-2020-07-16/15468/1
from launch.
Related Issues (20)
- Bug or feature? PushRosNamespace is not forwarded to managed actions HOT 4
- XMLLaunchDescriptionSource: Unknown substitution: find HOT 1
- [FeatureRequest] Is it possible to skip argument checking in include_launch_description
- Launch doesn't stop running nodes when exception thrown HOT 2
- Can't include [launch_testing_ament_cmake] in a launch only package HOT 1
- Bug when setting launch arguments of included descriptions HOT 1
- Requirement:Only start all nodes and then this ros2 launch process exit HOT 2
- `ExecuteProcess` with `shell=True` gets incorrect exit code from the executed process HOT 2
- Add an option to disable creating log files by the launch system HOT 1
- Unexpected YAML parsing with get_attr and List[Entity] type HOT 1
- pytest 8.1 incompatibility: TypeError: import_path() missing 1 required keyword-only argument: 'consider_namespace_packages' HOT 3
- Tests on Windows falsely positive reporting passed due to SIGINT handling HOT 1
- ThisLaunchFileDir throws error in debug mode
- Change ISSUE_TEMPLATE.md HOT 1
- Return Code not set on SIGINT HOT 3
- RegisterEventHandler: action_matcher must be an 'ExecuteProcess' instance or a callable HOT 2
- Request for Release in Iron HOT 2
- Feature request: run multiple tests in parallel with `colcon test` HOT 3
- Default port and address of 'foxglove_bridge_launch.xml' not met when launching HOT 1
- Parameterized `launch_pytest` tests don't close node log files HOT 1
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 launch.