-
Notifications
You must be signed in to change notification settings - Fork 14
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
Image: Update cXs images with missing python library #77
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❤️
516a506
to
35a4508
Compare
a0d410d
to
9392d51
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Messy but as long as it works I suppose it LGTM :)
It does not work 😢
|
79090bf
to
10d3b39
Compare
The current state is that |
10d3b39
to
99413b7
Compare
@thozza the status of this PR is that I extended c9s with |
//"python3-autopep8", // not available in cXs | ||
//"python3-boto3", // not available in cXs | ||
//"python3-botocore", // not available in cXs | ||
//"python3-docutils", // not available in cXs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, the intention with the commented out items was to keep the list the same with Fedora container, with the packages that are not available in cXs commented out with an explanation. Because it may be confusing to have some tools installed as an RPM package in Fedora, but using pip in centos.
If not a big deal, I would keep it that way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably can't keep comments with the new list, right? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me describe the whole story:)
For easier modification / review it is the best to keep this as a multi line string (as before). The problem is that bake syntax allows multiline string in here-doc format only. The other problem is that it was impossible in bake to append inherited variable from base image, so the only way to have this common module list was to put it as a separate variable.
There are three possible solutions, each one not perfect:
- I will add all the comments on top of the new variable but they will no longer be inline comments
- I could add them inline and modify dnf script processing it later to filter them out when it is processing list of packages.
- Copy paste the list with comments to each image definition with it own comments (which kills the whole inheritance idea).
I would opt for option (1) as I agree it is worth to keep those comments
99413b7
to
b05c2f6
Compare
No description provided.