suggestion: allow for relative paths in grm repos find

[pythys]

For example the command grm repos find local apache --format yaml > apache.yml creates my file as expected, however I have a problem.

The root is defined as ~/whatever/is/the/path which is not suitable in my case. I want it instead to be ./whatever/is/the/path meaning it should be relative to my current directory. Why? Well because I have a full repository right now that manages my other repositories, has a build script and other complex work. That repository needs to download stuff relative to its location, NOT the home directory.

So my suggestion is either to make it by default relative and you have to type the absolute path if you want to (preferred) OR alternatively pass a flag e.g. --relative to the find command

Take a look at the tree structure for example:

Permissions Size User  Date Modified Name
drwxr-xr-x     - taher  7 Jan 14:16  .git/
drwxr-xr-x     - taher 23 Dec  2022  apache/
drwxr-xr-x     - taher 25 Dec  2022  fork/
drwxr-xr-x     - taher  7 Jan 13:52  infra/
drwxr-xr-x     - taher 18 Dec  2022  moqui/
drwxr-xr-x     - taher 30 Dec  2022  nested/
drwxr-xr-x     - taher  3 Jan 13:54  project/
drwxr-xr-x     - taher  1 Jan 18:22  public/
drwxr-xr-x     - taher  7 Jan 13:52  taher/
.rw-r--r--    77 taher  7 Jan 13:53  .gitignore
.rw-r--r--   339 taher  7 Jan 14:15  apache.yml
.rw-r--r--  1.2k taher  7 Jan 13:46  build.gradle
.rw-r--r--   486 taher  7 Jan 14:15  fork.yml
.rw-r--r--  2.7k taher  7 Jan 14:15  infra.yml
.rw-r--r--  4.7k taher  7 Jan 14:16  moqui.yml
.rw-r--r--   19k taher  7 Jan 13:54  nested.yml
.rw-r--r--  1.5k taher  7 Jan 14:16  project.yml
.rw-r--r--   494 taher  7 Jan 14:16  public.yml
.rw-r--r--   450 taher 26 Dec  2022  README.md
.rw-r--r--   970 taher  7 Jan 14:16  taher.yml

[hakoerber]

Yeah, the path handling in grm repos find local is quite unsatisfactory right now. There is a lot of room for improvement.

Note: Having relative paths as root in config.yaml already works currently. So you can at least manually fix the config.yaml after running find local.

I agree that grm repos find local should also support relatives paths for root in the output.

Let me summarize your suggestions so we are on the same page:

Suggestion 1:

• Keep the current logic as-is (i.e., by default, you will always receive an absolute path).
• Add a --relative flag as you suggested. In this case, the root in the output would always be relative to the current directory.
• Optionally, a flag like --relative-to <path> would do the same as --relative, but with the given value instead of the current directory.

Suggestion 2:

Derive the distinction between relative/absolute from the path given to grm repos find local. I.e.:

• grm repos find local ~/code => Absolute path
• grm repos find local ./code => Relative path

Is this what you mean with "make it by default relative and you have to type the absolute path if you want to"?

I actually like this one best. It's very simple: Whatever you pass to grm repos find local will also land in the configuration as root.

Implementation

The point where the path is converted to absolute is the call to Path::canonicalize().

I think implementation would be quite straightforward:

• Keep the current logic as-is (Path::canonicalize() etc), but save args.path beforehand.
• Use the saved value of args.path as the root in the output.

There are a few things that can be improved during that change:

• Because the root value of the tree:Tree returned by find_in_tree() is now useless (as it will be overwritten), it would be better to return a Vec<repo::Repo> instead of a tree:Tree, and construct the tree:Tree in the caller instead. We just have to be careful about proper handling of repositories in the search root (i.e. the repo_in_root stuff).
• Maybe we can even drop the call to Path::canonicalize(), or at least move it into find_in_tree().

---

What do you think? Would that be enough to cover your use case? Feel free to tackle the implementation and open a PR, as I am not sure how much time I can invest into this issue currently.

[martins-1992]

Suggestion 2 is a nice one, as most users, thereby, probably won't have to think about it this way. They will more likely get it the way they want, without thinking about it.

[pythys]

Yes relative paths work and I am already using it as such (fixed it by hand like you suggested).

IMHO complying with user input is the best design choice, meaning that the code decides whether this is a relative or absolute path based on user input, just like in bash itself. So for example:

• grm repos find local something relative to the directory ./something
• grm repos find local ./something relative to the directory ./something
• grm repos find local $SOME_VAR/something stores and perhaps later evaluates the var so $SOME_VAR/something
• grm repos find local ~/something is a home path to ~/something
• grm repos find local /home/my-user/one/two/three is an absolute path to /home/my-user/one/two/three

Simple, no surprises, and anyone who knows bash knows how this works and we're done. I will try to put something together to handle this ticket.

[pythys]

Maybe based on my examples above we can convert the root from a string to an actual expression that gets evaluated on each platform accordingly (bash / powershell / DOS) by simply relegating it to the platform to expand the expression. I'm not sure if this is far fetched but hey I'm just dumping ideas right now.

[hakoerber]

Maybe based on my examples above we can convert the root from a string to an actual expression that gets evaluated on each platform accordingly (bash / powershell / DOS) by simply relegating it to the platform to expand the expression. I'm not sure if this is far fetched but hey I'm just dumping ideas right now.

Yeah, good idea. There are lots of things to improve. Env variable expansion does not work currently (except for $HOME). If you want, feel free to open another issue to track improvements to the handling of root, so we can discuss ideas.

I will try to put something together to handle this ticket.

Awesome, looking forward to your PR!

[pythys]

closing this ticket, thank you for the feedback, we'll handle root in a separate ticket later once I have substantial code as discussed