in util.version.py::get_project_path(), consider calling modules to report VERSION correctly #109
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When derived modules (i.e. viral-classify) are symlinked into
viral-core
and their versions are read from aVERSION
file, only the path to the viral-core version file was read.This changes that behavior, so outer members of the call stack are checked for the presence of VERSION files as well (and if found, the version is read from the first/outermost one found).
(i.e. when calling
./taxon-filter.py --version
, with these changes, the version ofviral-classify
is correctly returned rather than the version ofviral-core
)Since this relies on the presence of a
VERSION
file to find the current "project path", this will fall back to the old behavior ifviral-core
has aVERSION
file but the derived module lacks such a file.This does not change the existing behavior where a version file will not be created for a derived module when calling
./symlinked_derived_module.py --version