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

Pathing issues with meta/execution-environment.yml #414

Open
nitzmahone opened this issue Sep 1, 2022 · 3 comments
Open

Pathing issues with meta/execution-environment.yml #414

nitzmahone opened this issue Sep 1, 2022 · 3 comments

Comments

@nitzmahone
Copy link
Member

Clearly we have a design problem with reusing the EE def for dependency exchange that needs to get sorted with the next batch of builder changes. Ideally we can come up with a way to make the metadata EE def buildable, but if not, document it as such or replace it with a bespoke metadata exchange file. Relative file path assumptions are definitely problematic, and will only get more so as we provide more ways to include other files in the generated build context.

theforeman/foreman-ansible-modules#1466
theforeman/foreman-ansible-modules#1471
#406
#399

@github-actions github-actions bot added the needs_triage New item that needs to be triaged label Sep 1, 2022
@eqrx eqrx removed the needs_triage New item that needs to be triaged label Sep 6, 2022
@Shrews
Copy link
Contributor

Shrews commented Sep 6, 2022

I'd be curious as to what folks actually expect of an EE def file contained within a collection when it is used to build an EE. Is it expected to pull in the collection in which it is contained in a new step? Currently, this file is read only after a collection has been installed (for dependency requirements only).

@maxamillion
Copy link

@nitzmahone @Shrews I'm not sure if this issue is still valid, but personally I'd like to see the exec env definition be hosted inside the collection fwiw :)

@nitzmahone
Copy link
Member Author

I don't see how that's a generally useful thing though- an EE definition for nearly all purposes is a usage-specific thing that composes N collections on a container base image with a specific Python, core, runner, and the deps all those collections declare. Separately, a collection needs a standard way to expose its deps- $someone decided at some point to conflate those two things, and it caused a whole bunch of problems.

Nobody ever asked me the question "how should a collection declare its deps?"- this just ... happened organically somewhere along the line, and we've been dealing with the fallout ever since- community collections decided they wanted to use it for DRY on their requirements to generate test EEs for CI, and someone complained enough to the folks that were developing builder that they just added support for looking in meta/, and now we're kinda stuck with it. I don't see any benefit to users whatsoever for hosting EE defs in collections. Is this an ELI5 that I'm just being dumb about?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

No branches or pull requests

4 participants