Run 'haros init' in the build dir (instead of $HOME)

[gavanderhoorn]

Current implementation appears to run haros init without any special configuration, which would place all haros configuration and plugin meta-data in $HOME of the current user.

Perhaps OK for normal usage, but it might be better to not do that when run as part of a catkin_make run_tests run to avoid polluting a user's $HOME and/or any existing haros installation.

It's unclear whether haros init actually accepts alternative locations -- and whether "the rest" of haros accepts non-standard locations -- but that would be something to investigate.

[gavanderhoorn]

@git-afsantos: would Haros support storing everything in a directory not in $HOME/.haros?

I'm guessing the HarosInitRunner would need to be changed?

[git-afsantos]

Indeed, to support alternative directories I would have to make some changes. The single directory approach is something that has been bothering me too for a while.

I am currently fixing some other issues in Haros, so I might tackle this right after.

[gavanderhoorn]

I don't necessarily just want to dump this on your TODO list.

Do you have some ideas for what you'd like to change?

The init runner seems straightforward enough. Adding an additional arg to the init verb would probably be sufficient, correct?

All the other verbs would probably also need to be extended to accept an additional arg telling them where the ".haros"-dir is (which wouldn't necessarily be called that any more).

[git-afsantos]

Since this change affects all verbs, it is probably best for the argument to be passed to the haros command itself (like --debug is). I.e.,

haros --home /my/new/haros/dir <VERB> <ARGS>

In terms of the code itself, the argument would be introduced around this line, with the default value of os.path.join(os.path.expanduser("~"), ".haros").

Then each verb runner (init, analyse, export, viz) would find & replace self.HAROS_DIR with args.home (args.root, args.haros_dir, or whatever it is called).

[git-afsantos]

This line would have to be changed as well:

https://github.com/git-afsantos/haros/blob/ebf1bf3b6d23249c716c3d53ce3409b50aa8e067/haros/haros.py#L139

[git-afsantos]

@gavanderhoorn is your suggestion to place .haros somewhere else besides $HOME, or to use some other directory in place of .haros? I.e., /path/to/.haros versus /just/some/path?

The latter requires a little bit more work to implement.

[git-afsantos]

git-afsantos/haros#71 is a candidate PR to implement this.
It implements the easier create .haros in the given dir option.

[gavanderhoorn]

is your suggestion to place .haros somewhere else besides $HOME, or to use some other directory in place of .haros? I.e., /path/to/.haros versus /just/some/path?

the latter.

But the former could be a work-around for now.

[git-afsantos]

git-afsantos/haros#71 has been updated. The directory given to --home will be used directly in place of ~/.haros.

Additionally, init is not needed anymore, unless you want to force the expected structure of .haros (i.e., overwrite files if needed). I will probably deprecate and remove this verb at some point.

---

Released in Haros 3.5.0.
BTW, this is yet untested, but I suspect that with different --homes Haros can now run multiple instances in parallel. Is this your intended use?

[gavanderhoorn]

BTW, this is yet untested, but I suspect that with different --homes Haros can now run multiple instances in parallel. Is this your intended use?

As I mentioned in the meeting we just had: this wasn't directly related to running multiple Haros instances in parallel, but it should make it possible, yes, and that is actually going to help quite a bit later on.

Primary motivation was to be able to put the .haros dir in the build space of a workspace so we don't accidentally reuse a .haros from another run.

[gavanderhoorn]

@git-afsantos: I'm using Haros with git-afsantos/haros#71 (ie: v3.5.2) and the initial init seems to work.

But a subsequent analyse throws errors:

$ rosrun haros_catkin haros --home=/tmp/ws/build_isolated/test_pkg/haros_home -c /tmp/ws/src/haros_catkin_test/test_pkg analyse -d /tmp/ws/build_isolated/test_pkg/test_results/haros_report
Traceback (most recent call last):
  File "/tmp/ws/devel_isolated/haros_catkin/share/haros_catkin/venv/bin/haros", line 10, in <module>
    sys.exit(main())
  File "/tmp/ws/devel_isolated/haros_catkin/share/haros_catkin/venv/lib/python2.7/site-packages/haros/haros.py", line 764, in main
    if launcher.launch(argv = argv):
  File "/tmp/ws/devel_isolated/haros_catkin/share/haros_catkin/venv/lib/python2.7/site-packages/haros/haros.py", line 149, in launch
    return args.command(args)
  File "/tmp/ws/devel_isolated/haros_catkin/share/haros_catkin/venv/lib/python2.7/site-packages/haros/haros.py", line 178, in command_analyse
    raise ValueError("Not a file: " + args.package_index)
AttributeError: 'Namespace' object has no attribute 'package_index'

all directories exist and /tmp/ws/build_isolated/test_pkg/haros_home seems to contain the expected content.

Any ideas?

PS: would you want me to open an issue on the haros tracker?

[git-afsantos]

Wow, you ran into two bugs at once! Good catch!

So, basically, it was looking for the default $HOME/.haros/index.yaml, despite the use of --home.
Haros 3.5.4 🚢 should fix that. 🐛 🔨

[gavanderhoorn]

Nice. I'll test. Thanks for the quick fixes.

Btw, I noticed that the github repo releases page doesn't appear to list all releases that pypi has. Is that intentional?

[git-afsantos]

That is just me remembering the existence of that page only when I have a somewhat major release on my hands. Thanks for the reminder, I should update it sometime soon. 👍

[gavanderhoorn]

Seems to work now, but I'm seeing [HAROS] Running setup operations... twice.

Afaict I init the same directory as I use for --home. Is init automatically invoked by the other verbs/commands?

[git-afsantos]

Yes, when I added the --home option, init basically became obsolete. You should not need it, unless you want to force a reset on the directory.

[gavanderhoorn]

I'm not entirely sure yet, but I believe not running init separately results in another traceback.

I'll verify and report back.

[git-afsantos]

Ah, I see. Given your command above, it is probably complaining with

ValueError: Not a file: /tmp/ws/build_isolated/test_pkg/haros_home/index.yaml

I should be able to fix that soon.

[gavanderhoorn]

Yes, indeed. That's the error:

Traceback (most recent call last):
  File "/tmp/ws/devel_isolated/haros_catkin/share/haros_catkin/venv/bin/haros", line 10, in <module>
    sys.exit(main())
  File "/tmp/ws/devel_isolated/haros_catkin/share/haros_catkin/venv/lib/python2.7/site-packages/haros/haros.py", line 763, in main
    if launcher.launch(argv = argv):
  File "/tmp/ws/devel_isolated/haros_catkin/share/haros_catkin/venv/lib/python2.7/site-packages/haros/haros.py", line 149, in launch
    return args.command(args)
  File "/tmp/ws/devel_isolated/haros_catkin/share/haros_catkin/venv/lib/python2.7/site-packages/haros/haros.py", line 179, in command_analyse
    raise ValueError("Not a file: " + project_file)
ValueError: Not a file: /tmp/ws/build_isolated/test_pkg/haros_home/index.yaml

[git-afsantos]

Haros 3.5.5 should fix that 🚢

[gavanderhoorn]

Yep, fixed.

Thanks again.

[gavanderhoorn]

This is now supported in Haros, and we can configure it in haros_catkin now that #19 was merged.