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

ros2_batch_job --workspace-path option does not work #600

Open
jacobperron opened this issue Nov 10, 2021 · 1 comment
Open

ros2_batch_job --workspace-path option does not work #600

jacobperron opened this issue Nov 10, 2021 · 1 comment
Labels
backlog bug Something isn't working

Comments

@jacobperron
Copy link
Member

jacobperron commented Nov 10, 2021

Looking at the code we see that the argparse option declared here:

parser.add_argument(
'--workspace-path', default=None,
help="base path of the workspace")

is not actually used anywhere in the code. So setting this option has no affect on the job.

I'm not sure exactly how to fix the argument because I don't understand the purpose of the --white-space-in option, which is coupled to determining the actual workspace named used:

args.workspace = 'work space' if 'workspace' in args.white_space_in else 'ws'

If I'm not mistaken, this section of code is relevant as well:

for name in ('sourcespace', 'buildspace', 'installspace'):
space_directory = getattr(args, name)
if name in args.white_space_in and space_directory is not None:
raise Exception('Argument {} and "--white-space-in" cannot both be used'.format(name))


Here are other references to the option I could find:

export CI_ARGS="--do-venv --force-ansi-color --workspace-path $WORKSPACE"

set "CI_ARGS=--force-ansi-color --workspace-path !WORKSPACE!"

set "CI_ARGS=--force-ansi-color --workspace-path !WORKSPACE!"

@jacobperron jacobperron added the bug Something isn't working label Nov 10, 2021
@clalancette
Copy link
Contributor

I'm not sure exactly how to fix the argument because I don't understand the purpose of the --white-space-in option, which is coupled to determining the actual workspace named used:

The purpose of --white-space-in is to test out that our build and install stack (colcon and ament) handle whitespaces in paths properly. This is particularly relevant on Windows, where whitespaces are often found in paths.

That said, I'm guessing that this option is rarely, if ever, used. I'd be OK with removing the option altogether; while we should test whitespaces-in-path somehow, this doesn't seem like the right way to do it. Thoughts from anyone else?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backlog bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants