Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add command to start a development container using the current / specified env #19

Open
fmauch opened this issue May 20, 2024 · 1 comment
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@fmauch
Copy link
Contributor

fmauch commented May 20, 2024

We could support developing inside containers using robot_folders a bit more.

As I am not using throwaway containers for my development on a daily basis, I don't feel like I should go ahead and implement this, at least somebody should give their thoughts on this, hence the "help wanted" label. If you would like to see this feature happen and got some experience in that regards, please share them here so we can actually make this feature useful. Or even you might want to contribute yourself?

Description

e.g. we could provide a fzrob docker command with the following subcommands

  • build for building a development image. We could provide a base dockerfile that could be re-used parametrized with the ROS distribution (basing FROM ros:<distro>)
  • start for starting a container with that image. This could bind-mount the current env's root dir (or only the source dirs and the demos dir?) into the container in order to have the source files persistently available, also on the host system.
  • stop for stopping a container with that image
  • commit to stage the current container

We might also support the devcontainers specification instead of only using Dockerfiles... I guess?

Things to consider

  • underlays need to be handled explicitly (copied / mounted into the container)
@fmauch fmauch added enhancement New feature or request help wanted Extra attention is needed labels May 20, 2024
@taDachs
Copy link
Contributor

taDachs commented May 21, 2024

another option would be to generate a new docker image from the underlay workspaces with the packages already built and installed (depends on the workflow, if one has to often touch those workspaces this might be suboptimal).

Regarding devcontainer specification: it brings a lot to the table, especially stuff like devcontainer-features. For me it's the one thing that enables me to still use my favorite cli tools without (re)writing a dockerfile for every project. Also it gives a nice separation between the "build" dependencies (libraries etc) and the "development" dependencies (compiler, linter, language server, editor etc.).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants