This message was deleted.
# general
s
This message was deleted.
l
From the looks of the Dockerfile, it just grabs a base python image and base pulumi image, and copies relevant files between them. https://github.com/pulumi/pulumi/blob/master/docker/python/Dockerfile
It should be pretty easy to nab that file, update the RUNTIME_VERSION, build a new Pulumi image for your own use, and push it to your own Docker registry.
No real building required.
e
Cool - thanks @little-cartoon-10569. Any reason the official one is 3.7.7? i.e. worth a PR?
r
Feel free to submit a PR! I don’t think there’s any specific reason that it’s 3.7.7.
🙌 1
h
excellent initiative - i was going to ask this myself! i left a comment on the PR regarding considering leaving out the patch version for python, seeing as patch bumps bring in bugfixes and security updates. thoughts?
l
In general, for any application potentially used in the production of systems with regulatory requirements, documented specific versions make life easier.
The auditors are happier.
That said, a selection of tags pushed to GitHub would be fine, including versions for 3.7, 3.8, latest etc....
The cost on Pulumi would be minimal.. just a few extra cloud build minutes each month.
(All just IMO, of course.)
h
i get your point - but locking versions applies to minor versions, right? IMO, it's desirable to have 3.9.x instead of 3.9.4 with the .x bumped automatically via upstream changes to the python docker image. patch versions don't change functionality AFAIK. please do correct me if i'm wrong
l
That's the ideal approach, I think. But not all auditors would agree with you 🙂
But if an org wanted a specific, locked-down version, then a good way to do that would be to grab a specific image, push it to your own registry, and eliminate the "risk" of change that way. That would probably make them even happier 🙂
Bugs can creep in even in patch versions..
h
what can of worms have i opened...
l
Anything where the answer can be "auditors" just gets me going... sorry...
e
Heh, just catching up on this one. I actually updated it to use the default 3.9 build as suggested by @handsome-state-59775: https://github.com/pulumi/pulumi/pull/6706
I can see args both ways, but given it's the official python builds and Pulumi advertises support for "3.6 or later", I'd expect the CI container to be based on whatever is the latest 3.9.x release. Hopefully we can go to 3.10.0 soon enough 🙂
👍 1
cc @little-cartoon-10569
r
Just a heads up about 3.10. I believe it is scheduled to release in October 2021, but it’ll probably take us a while longer before Pulumi can support it as we have dependencies like protobuf and grpc that will need to be updated before we can change over.
👍 1
e
That's helpful for our planning @red-match-15116. FWIW the few documented breaking changes (removals) for the 3.10 rc have been deprecated at least one (mostly quite a few) point releases ago. Hopefully any dependencies are updated in short order. Do you have an github issue/ PR for tracking 3.10 compatibility?
r
Not yet! Feel free to open one :)