introduce include to load sub-compose projects as dependencies#416
introduce include to load sub-compose projects as dependencies#416glours merged 1 commit intocompose-spec:masterfrom
Conversation
2cdf161 to
f66a32e
Compare
include to load sub-compose projects as dependencies
include to load sub-compose projects as dependencies1064c01 to
bad8119
Compare
glours
left a comment
There was a problem hiding this comment.
Sounds good to me, you just need to fix the conflict before merging
| return requires, err | ||
| } | ||
|
|
||
| var transformIncludeConfig TransformerFunc = func(data interface{}) (interface{}, error) { |
There was a problem hiding this comment.
nit: can't we use generics here?
There was a problem hiding this comment.
this signature isn't a "lack of generics": those manage the parsed yaml nodes, which are actual interface{}
| err := ResolveRelativePaths(project) | ||
| if err != nil { | ||
| return nil, err | ||
| } |
There was a problem hiding this comment.
nit: could also be apply to the following if !opts. blocks
| err := ResolveRelativePaths(project) | |
| if err != nil { | |
| return nil, err | |
| } | |
| if err := ResolveRelativePaths(project); err != nil { | |
| return nil, err | |
| } |
There was a problem hiding this comment.
I personally consider those to have lower readability for the tiny benefit of a single line being saved
especially as the "long" syntax is displayed in my goland IDE as a single "error handling" line:
err := ResolveRelativePaths(project)
if err != nil : nil, err ⮑There was a problem hiding this comment.
As you wish, I don't have a strong opinion about this 😉
loader/testdata/compose-include.yaml
Outdated
|
|
||
| services: | ||
| foo: | ||
| image: foo No newline at end of file |
21a9ed8 to
aae3bba
Compare
Signed-off-by: Nicolas De Loof <[email protected]>
|
Could it work with URL later ? |
|
@vasilvestre this is indeed something we consider for future, also see compose-spec/compose-spec#288 |
|
The functionality to include the remote file would be a great addition to this feature 🚀 for example: We could leverage this feature to re-use Compose files across teams. Currently, we’re cloning an additional repository solely to include another Compose file, which feels a bit cumbersome. 🤔 The mentioned compose-spec/compose-spec#288 seems like a broader feature with a much larger scope. While it could also address this problem, it approaches it from a different perspective. |
This adds support for
includeattribute introduced in the compose-specification by compose-spec/compose-spec#363This supports including compose sub-projects, comparable to language dependency management
usage:
required projects are resolved based on their own project directory to avoid relative path hell.