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

PEP 668: Keep the marker file in container images #2289

Merged
merged 1 commit into from
Mar 18, 2022

Conversation

pradyunsg
Copy link
Member

This preserves the protections afforded by these changes, in container
images.

See this comment for context.

This preserves the protections afforded by these changes, in container
images.
Copy link
Member

@CAM-Gerlach CAM-Gerlach left a 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?

@pradyunsg
Copy link
Member Author

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. :)

@CAM-Gerlach CAM-Gerlach requested a review from doko42 February 2, 2022 09:47
@dstufft
Copy link
Member

dstufft commented Feb 3, 2022

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.

@pradyunsg
Copy link
Member Author

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.

@pradyunsg
Copy link
Member Author

So... what do I need to do to get this landed? 🙃

@JelleZijlstra
Copy link
Member

I can push the button but I feel like we should get approval from @dstufft.

@pradyunsg
Copy link
Member Author

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. :)

@JelleZijlstra
Copy link
Member

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.

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

Successfully merging this pull request may close these issues.

7 participants