-
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
Python docker image build #141
Conversation
OMG! This is fantastic @rienafairefr I am testing this right now :) |
Ok, I have figured out the issue with the build on the init.py file and opened the bug linked for this. There is 1 small issue in your PR - the new test doesn't have a requirements.txt file in it so it's failing to build the deps I will be able to shepherd this across the line once up have the upstream bug fixed Thanks so much for all your work here Paul |
That's a weird edge case pulumi/pulumi-terraform-bridge#119 that this PR uncovered, well, let's wait for that. I've added what I think was the missing requirements.txt :-) |
@rienafairefr I will be working on fixing that up next week :) I am very keen to get this work into the system! |
Fixes: pulumi/pulumi-terraform-bridge#119 This allows us to specify an overlays block e.g. ``` Overlay: &tfbridge.OverlayInfo{ DestFiles: []string{ "pulumi_docker/docker.py", "pulumi_docker/image.py", }, }, ``` The overlays files are treated differently to normal module files as they are not generated. This structure means that we will emit the correct entries in the __init__.py file Without this structure (ie. pulumi_pkgname), the generator actually copies the file (i.e. docker.py) to the root of the Python SDK. This is because the structure of the Python SDK has a sub-folder than that of the NodeJS SDK I tested this using PR pulumi/pulumi-docker#141 and this now works as expected and we can take advantage of the new Python overlays for Docker
Fixes: pulumi/pulumi-terraform-bridge#119 This allows us to specify an overlays block e.g. ``` Overlay: &tfbridge.OverlayInfo{ DestFiles: []string{ "pulumi_docker/docker.py", "pulumi_docker/image.py", }, }, ``` The overlays files are treated differently to normal module files as they are not generated. This structure means that we will emit the correct entries in the __init__.py file Without this structure (ie. pulumi_pkgname), the generator actually copies the file (i.e. docker.py) to the root of the Python SDK. This is because the structure of the Python SDK has a sub-folder than that of the NodeJS SDK I tested this using PR pulumi/pulumi-docker#141 and this now works as expected and we can take advantage of the new Python overlays for Docker
Fixes: pulumi/pulumi-terraform-bridge#119 This allows us to specify an overlays block e.g. ``` Overlay: &tfbridge.OverlayInfo{ DestFiles: []string{ "pulumi_docker/docker.py", "pulumi_docker/image.py", }, }, ``` The overlays files are treated differently to normal module files as they are not generated. This structure means that we will emit the correct entries in the __init__.py file Without this structure (ie. pulumi_pkgname), the generator actually copies the file (i.e. docker.py) to the root of the Python SDK. This is because the structure of the Python SDK has a sub-folder than that of the NodeJS SDK I tested this using PR pulumi/pulumi-docker#141 and this now works as expected and we can take advantage of the new Python overlays for Docker
0be9482
to
692d6b4
Compare
Now that pulumi/pulumi-terraform-bridge#119 is down, what's the next step ? |
@rienafairefr apologies - I was away for a little while - I am working on integrating this to master now :) |
Unfortunately, I am not able to get this to work... I made a few small changes to the PR as follows:
These changes allow this to build as expected. but when I run the tests, dockerfile-py fails with the following error:
I 100% have docker available because it's running all of the other tests. It seems t be failing when trying to check the docker build . Thoughts here? It seems to not be able to launch the docker subprocess which seems strange Paul |
Thanks Paul @stack72 for the review. Looking at it again, the way the I'll see that the env= value passed to docker build augments the existing env instead of overwriting, that might fix the issue example mac os-specific issue with subprocess env: https://bugs.python.org/issue12383 |
Yep, as suspected, from the python docs, "If env is not None, it must be a mapping that defines the environment variables for the new process; these are used instead of the default behavior of inheriting the current process’ environment. It is passed directly to Popen." |
@stack72 I pushed a fix for the |
This is a great fix - I just ran the tests right now and everything is working as expected :) I cannot thank you enough for this work! It's going to make life a lot easier for everyone using this package I am going to merge this manually as I have 1 formatting fix to the Makefile to update - and I will rebase this Thanks again!! Paul |
Manually merged and pushed to master! |
Good news @stack72 ! There's still an issue with the async code that I mentioned ( |
The docker building was limited to the JS/Typescript runtime, and it's been missing when using the Python runtime. @adir-intsights issue #129 mentioned it. I went ahead and straight ported the javascript code. There is now a py example
dockerfile-py
which builds and tag an image, it seems to work.There is still an issue with async code I can't pinpoint (something in the Output/apply does not await),
/usr/lib/python3.7/asyncio/base_events.py:405: RuntimeWarning: coroutine 'Output.future.<locals>.get_value' was never awaited
, but at least the image is built fine. The rest of the functionalities (connect to registry, push, etc), are untested, and may be badly ported so care/test is needed. Python versions compatilibites might be fucked up as well, tested only on py 3.7Fixes: #129