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

Add dockerfile #1099

Closed
wants to merge 3 commits into from
Closed

Add dockerfile #1099

wants to merge 3 commits into from

Conversation

corona10
Copy link

#1096 Simply make develop environment by using docker

  • docker build -no-cache --tag pyston:latest ./ for make image
  • docker run -i -t pyston:lates for run image

p.s May be we can provie daily image from https://hub.docker.com/ by using AUTOMATED BUILD but need some test (As far as I know there are some cache issue. this script should always clone latest branch but dockerfile may skip if there is same instruction already executed. I don't know whether AUTOMATED BUILD support -no-cache option.)

@corona10 corona10 closed this Feb 16, 2016
@corona10 corona10 reopened this Feb 18, 2016
@corona10 corona10 mentioned this pull request May 7, 2016
@kmod
Copy link
Collaborator

kmod commented Jun 8, 2016

So right before the 0.5 release I looked into docker stuff and ended up adding a Dockerfile -- I took a bit of a different approach with it, where it downloads the latest release instead of following our build-from-scratch instructions. This seems to be the common way that other projects handle it (at least, that's how CPython and PyPy's work).

It might be nice to have a dockerfile that generates a dev environment. I think docker isn't really meant for this sort of thing (it doesn't want you to keep any state or treat the containers like vms), but I've definitely used it like that and it seems to work fine. So in that sense this could still be useful, but I'm worried about the download size -- the llvm directory and build directory add up to several gb. Maybe for this use-case ("quickly setting up a Pyston dev environment") we should go with Vagrant and try to take #1104 / #1147 to completion? (It looks like #1104 is just missing docs.)

Also, we should move this Dockerfile out of the top level, since docker build will import everything from the Dockerfile's directory into the container.

@funkyfuture
Copy link

funkyfuture commented Nov 11, 2016

fyi, here is a two-layer image based on Ubuntu Xenial as reference.

i used the build-approach as the virtualenv doesn't fit into my concept. a virtualenv is also rather a redundant isolation layer in a container.

the build works well, but the vast amount of package dependencies - including lots of latex related stuff - is hell. this renders automated builds on the docker hub impossible due to the limited resources there.

@kmod
Copy link
Collaborator

kmod commented Nov 11, 2016

I'm going to close this because I think it is quite unlikely that a build-based dockerfile will be what we want -- as you said it will prevent automatic builds, and there isn't much benefit to it. Separating the packaging from the building seems reasonable as well.

I don't think we can get around using virtualenv inside the container, at least if we want to provide a "Pyston environment" and not just a "Pyston binary". Yes it's multiple layers of isolation, but docker containers don't remove the need to separate app and system pythons. Maybe there's some better way of solving it, but providing a virtualenv makes it so that we can address the common use case of people who want to run numpy on Pyston.

@kmod kmod closed this Nov 11, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants