Nested local.include doesn't work as expected
See original GitHub issueDescription
It seems that local.include
always evaluates the path relative to the top level deploy, or rather, the one specified on the command line. This causes issues with nested deploys that include other deploys, which in turn contain others if some of these deploys are in a different location on the directory tree.
For example, with this structure:
.
├── data
├── deploys
│ ├── facts
│ ├── roles
│ │ └── group_data -> ../../group_data
│ └── tasks
│ └── group_data -> ../../group_data
├── group_data
└── inventories
The tasks
dir is used to store building-block deploys for reuse which may need to be called in a very specific order, while the roles
dir contains deploys made up of groupings of tasks
(and other additional operations) that are “guaranteed” to work together.
This issue crops up in the following scenario:
- Deploys
A.py
andB.py
are intasks
. A.py
useslocal.include
to includeB.py
.- Deploy
C.py
is inroles
. C.py
useslocal.include
to includeA.py
.
This causes an error when trying to run pyinfra <inventory> deploys/roles/C.py
, because the local.include
in A.py
attempts to use a relative path based on the location of C.py
, which is invalid.
Expected behavior
I feel like it makes more sense for local.include
to evaluate the path relative to the location of the deploy file that it is in so that nesting would “work as expected.”
Meta
❯ pyinfra --support
--> Support information:
If you are having issues with pyinfra or wish to make feature requests, please
check out the GitHub issues at https://github.com/Fizzadar/pyinfra/issues .
When adding an issue, be sure to include the following:
System: Darwin
Platform: Darwin-18.7.0-x86_64-i386-64bit
Release: 18.7.0
Machine: x86_64
pyinfra: v1.1.2
Executable: /Users/----/.local/bin/pyinfra
Python: 3.7.8 (CPython, Clang 10.0.1 (clang-1001.0.46.4))
- Installed via
pipx
Issue Analytics
- State:
- Created 3 years ago
- Comments:8 (5 by maintainers)
Top GitHub Comments
@Fizzadar Cool, I will try that out once
v1.4.13
is released. Thanks!Seems to be working, but the logging looks odd because it keeps appending the dirname of the relative path multiple times in some cases. Here is an example (still works correctly though):
Maybe it would make sense to only show the
abspath
for the included file?