Added support for inheritance in importing repository files.

[leander-dsouza]

Basic Info

Info	Please fill out this column
Ticket(s) this addresses	#148
Primary OS tested on	Ubuntu
Is this a breaking change?	No
Does this PR contain AI generated software?	No

---

Description of contribution in a few bullet points

• Added an extends field for vcs import to facilitate inheritance.
• Added safeguards for avoiding circular imports.
• Updated the testing framework to account for various edge cases regarding the extends feature.
• Updated the README to include information on how to use the new field.

Description of how this change was tested

• Ran pytest locally to ensure all the unit and linting tests pass:

  pytest -s -v test

• Created a local fork to validate green CI.

Signed-off-by: Leander Stephen Desouza leanderdsouza1234@gmail.com

[christophebedard]

Some comments and suggestions.

---

More of a long-term, high-level discussion: Did you see the discussion on the original PR about being able to extend multiple files and import multiple files and the semantics of that? dirk-thomas/vcstool#148 (comment). How do you think that should behave? Dirk was suggesting not allowing (warning or erroring on) identical entries for sibling files: not allowing two files being extended to contain the same repository path (e.g., src/vcs2l: under repositories:). I think I kind of missed that back then and intended to just merge sibling entries and prioritize from top to bottom instead:

extends:
  - a.repos  # May override entries from b.repos
  - b.repos
repositories:
  repo: ...  # May override entries from the combination of a.repos and b.repos

We can probably figure this out after this PR, though.

[leander-dsouza]

Some comments and suggestions.

More of a long-term, high-level discussion: Did you see the discussion on the original PR about being able to extend multiple files and import multiple files and the semantics of that?

Yes, it was quite straightforward to extend the implementation to support multiple files.
The very last commit of this PR is focused on tackling this.

I have included documentation, tests and error support if the user tries to include duplicate files.

[leander-dsouza]

I can understand that the documentation can take up a lot of space in the README.
I was hoping that upon review of this PR, we can safely migrate this into specific pages in the documentation:

https://ros-infrastructure.github.io/vcs2l

[christophebedard]

More of a long-term, high-level discussion: Did you see the discussion on the original PR about being able to extend multiple files and import multiple files and the semantics of that?

Yes, it was quite straightforward to extend the implementation to support multiple files. The very last commit of this PR is focused on tackling this.

I have included documentation, tests and error support if the user tries to include duplicate files.

Sorry, I meant to initiate a discussion and not really request you to implement something, because, from the initial discussion with Dirk, there were two options when supporting multiple files under extends:, and I wasn't sure what the best option was:

1. Allow files to include the same repository path (e.g., two files including src/vcs2l: under repositories:), but define precedence, e.g., bottom file takes precedence, like you did
2. Do not allow files to include the same repositories; report an error

I think Dirk's point was that it makes sense for a file extending another file to override some paths (repos), but it may or may not make sense for a file being extended to override some paths from another file being extended alongside it.

[leander-dsouza]

Sorry, I meant to initiate a discussion and not really request you to implement something

Apologies for misreading the conversation. I can drop the specific commit if this does not pertain to the PR.

I wasn't sure what the best option was:

1. Allow files to include the same paths, but define precedence, e.g., bottom file takes precedence, like you did
2. Do not allow files to include the same paths; report an error

I am currently not allowing the user to specify the same path by raising the error here.

I feel that this is a more simplistic approach, which limits the user to specifying distinct paths as part of the extended files.
I believe that by restricting this option, the file hierarchy becomes easier to track and follow.

Please let me know if this is a viable method to follow through, as this file structure can be restrictive and opinionated.

[christophebedard]

I wasn't sure what the best option was:

1. Allow files to include the same paths, but define precedence, e.g., bottom file takes precedence, like you did
2. Do not allow files to include the same paths; report an error

I am currently not allowing the user to specify the same path by raising the error here.

I feel that this is a more simplistic approach, which limits the user to specifying distinct paths as part of the extended files. I believe that by restricting this option, the file hierarchy becomes easier to track and follow.

Please let me know if this is a viable method to follow through, as this file structure can be restrictive and opinionated.

Sorry, my comment wasn't clear, especially without the original context. See my updated comments. By "the same paths," I meant the same repository paths (not .repos files paths), e.g., if two files being extended have src/vcs2l: under repositories:.

In any case, I think allowing identical repository paths/entries is fine for now. I can see having a --strict-extend option later to report an error in case of duplicate repository entries.

[leander-dsouza]

Sorry, my comment wasn't clear, especially without the original context. See my updated comments. By "the same paths," I meant the same repository paths (not .repos files paths), e.g., if two files being extended have src/vcs2l: under repositories:.

Oh my bad, I think since we are allowing duplicate repository entries as of now, this should be resolved.
By defining a priority structure (higher priority items stay at the bottom of the list), the ambiguities should nullify, and provide the user with a lot more flexibility.

I can see having a --strict-extend option later to report an error in case of duplicate repository entries.

Yes, sure. I can add this as a feature request issue once this PR gets merged with main.