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

[Fix] LocalRegistry known/fullname glob inconsistency #80

Merged
merged 1 commit into from
Oct 1, 2024
Merged

Conversation

g5t
Copy link
Collaborator

@g5t g5t commented Oct 1, 2024

The Reader asks each Registry in turn if it 'knows' a filename. If it does, that Registry is then used to retrieve the file 'fullname', 'path', or contents. In the case of LocalRegistry the component is searched for in a more-restrictive way for the three latter cases, allowing for the possibility that a LocalRegistry 'knows' it has a file but can't find it.

This makes the later checks less stringent, fixing #79, which could have the effect of allowing multiple matches for a file, especially if two copies of the same file (with modifications, presumably) exist in the same directory tree.

For now, this possible drawback is not blocking, since if there is a directory structure like

/
├ backup
│   └ ComponentA
│       └ ComponentA.instr
└ ComponentA
    └ ComponentA.instr

outside of the runtime directory, then one could specify -I /ComponentA or -I /backup/ComponentA (instead of -I /) to get just one copy of the same-named file in the LocalRegistry.
And a similar layout under the runtime directory would require moving or renaming of files.

The `Reader` asks each `Registry` in turn if it 'knows' a filename.
If it does, that `Registry` is then used to retrieve the file 'fullname', 'path', or contents.
In the case of `LocalRegistry` the component is searched for in a more-restrictive way for the three latter cases, allowing for the possibility that a `LocalRegistry` 'knows' it has a file but can't find it.

This makes the later checks less stringent, which _could_ have the effect of allowing multiple matches for a file, especially if two copies of the same file (with modifications, presumably) exist in the same directory tree.
@g5t g5t merged commit 98e1b1a into main Oct 1, 2024
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant