Skip to content

Conversation

milas
Copy link
Member

@milas milas commented Sep 19, 2023

With include'd Compose files, it's important to know the origin of each service to be able to properly resolve paths to them, for example.

A new FileMeta field on the Project type provides detailed access to the underlying file structure/hierarchy.

This replaces IncludeReferences and ComposeFiles, which were inconsistent and not comprehensive.

What Problem Does This Solve

In Compose itself, when we use x- fields for non-stable features, the "load" logic lives in the docker/compose codebase until stabilized.

That means it needs to resolve in relative paths there -- compose-go can't help because it doesn't know about the fields to begin with. However, if they came from an included file, IncludeReferences has the ProjectDirectory BUT there's no way to know where a service came from! The FileMeta tree combines ComposeFiles + IncludeReferences and, critically, additionally populates service back-references.

@milas milas added the enhancement New feature or request label Sep 19, 2023
@milas milas requested review from ndeloof and glours September 19, 2023 23:10
@milas milas self-assigned this Sep 19, 2023
With `include`'d Compose files, it's important to know the origin
of each service to be able to properly resolve paths to them,
for example.

A new `FileMeta` field on the `Project` type provides detailed
access to the underlying file structure/hierarchy.

This replaces `IncludeReferences` and `ComposeFiles`, which were
inconsistent and not comprehensive.

Signed-off-by: Milas Bowman <milas.bowman@docker.com>
@milas
Copy link
Member Author

milas commented Sep 19, 2023

Open to suggestions here: I actually originally had this as an entirely separate object returned along with the project, but ergonomically that's impractical to propagate deep down into Compose itself.

Hopefully this is a reasonable compromise. I'd love to revamp all this soon 🙃

@ndeloof
Copy link
Collaborator

ndeloof commented Sep 20, 2023

LGTM in terms of codebase

With include'd Compose files, it's important to know the origin of each service to be able to properly resolve paths to them, for example.

About this assumption: included service should have all path resolved already when resource is copied into project, so why is this needed?

@glours
Copy link
Collaborator

glours commented Sep 20, 2023

@ndeloof IIUC, in the case of service managed by the watch mode and coming from a included file, we lose the original directory from where the relative paths defined in watch section should be applied

@ndeloof
Copy link
Collaborator

ndeloof commented Sep 20, 2023

ok, so basically because we miss https://github.com/compose-spec/compose-go/pull/461/files#diff-3e93eb737303c2fd36bba9ddd3b891ad9fb906fda7dbf9e377ceacb5b89bd943R118-R124 by using a custom extension, make more sense now

@milas milas mentioned this pull request Sep 20, 2023
@milas milas marked this pull request as draft September 20, 2023 12:53
@milas
Copy link
Member Author

milas commented Sep 20, 2023

(Marking this as draft temporarily so it doesn't get merged - @ndeloof's PR @ #461 resolves the watch + include issue. I think this might be useful for the future, but not critical for today.)

@ndeloof ndeloof deleted the branch compose-spec:master November 13, 2023 17:45
@ndeloof ndeloof closed this Nov 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants