-
Notifications
You must be signed in to change notification settings - Fork 98
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
Comments
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). |
@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 :) |
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 |
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
The text was updated successfully, but these errors were encountered: