-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
PEP 668: Keep the marker file in container images #2289
Conversation
This preserves the protections afforded by these changes, in container images.
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.
LGTM, @pradyunsg! Is this ready to merge?
I'd be fine if we wait for at least one co-author to approve -- but yes, this is good to merge IMO. This has been discussed on https://discuss.python.org/t/10302 at some length now. :) |
If I recall the reason we made these changes was due tot he large number of docker images out there that currently have baked into them using pip to directly modify the package managers installed Python. Most of those are not images that have apt-get (or similar) running against a "live" image, but as part of the initial build process that created it. Thus making it less likely to cause problems. All in all, I don't particularly care what our recommendation is here. My biggest concern is just whether the problems that distros face in longer living machines typically apply to docker images, and if not does this end up causing more end user frustration than is warranted. Like in a completely greenfield environment, I would agree that it's a no brainer. Maybe it would make sense to keep this section, but soften it's recommendation to say that the recommendation only applies to existing docker images that are just upgrading Python, but new docker images shouldn't remove it. Maybe it's fine no matter what and we can just introduce the breakage. |
I think this is the case here. And, also (1) this section uses "should" (2) is a generally non-normalative section and (3) does not preclude redistributors from using whatever change management strategy they see fit for introducing this file/behaviour change. I don't think it makes sense for the PEP to elaborate on what the change management strategy should be -- the redistributors are in the best position to make the call on what works best for their ecosystem. |
So... what do I need to do to get this landed? 🙃 |
I can push the button but I feel like we should get approval from @dstufft. |
Either way works for me. This PEP has eight authors and I'm one of them (and so is @dstufft). I'm not sure how many authors y'all wanna wait on here. IIUC, this is the last remaining actionable thing for this PEP to be ready -- but I'll trigger another round of discussions on this before I poke Paul Moore for a pronouncement on the d.p.o thread. :) |
Ah sorry, I should have checked the author list—I was just going off the fact that Donald is the code owner here. But since you're an author and Donald didn't seem opposed, I'll just merge it. |
This preserves the protections afforded by these changes, in container
images.
See this comment for context.