add initial version of centos 5 with gcc 5.2

[msarahan]

This should not be merged. It is for demonstration purposes only right now.

In particular:

• the dockerfile needs to be pulling anaconda from master in its alias (rather than the use_hbb branch)
• the start script should point to some official image, not my personal one.

Ping @ilanschnell @csoja @groutr @kalefranz

[groutr]

Would it be better to remove python via yum?

[msarahan]

Good idea, but no. That python is part of what hbb adds, not something that
yum can manage.

On Thu, Jan 14, 2016, 17:02 Ryan Grout [email protected] wrote:

In docker-build-x86-64/Dockerfile
#20 (comment)
:

@@ -0,0 +1,34 @@
+from phusion/holy-build-box-64:latest
+
+# Install graphical libraries (some packages, such as Matplotlib, require them
+# at test time)
+run yes | yum install libX11-devel libSM libXrender
+run yes | yum install openssh-clients chrpath
+run yes | yum install vim-enhanced vim-common nano
+# We provide our own python. Remove HBB's version.
+run rm /hbb/bin/python

Wouldn't it be better to remove python via yum?

—
Reply to this email directly or view it on GitHub
https://github.com/ContinuumIO/docker-images/pull/20/files#r49799251.

[kalefranz]

@groutr yum is written in python :) So yum erase python would be deleting its own interpreter. Unless you meant something else?

[groutr]

So, probably not my brightest idea :) Didn't know yum was written in Python.

[groutr]

Seems to work fine for me.
EDIT: A better idea of system packages required would a good thing. For example, one the packages I built failed because unxz wasn't installed.

[seibert]

I second the request for xz in this image. The LLVM source code is now distributed in tar.xz form.

[msarahan]

@seibert @kalefranz @jjhelmus @pelson @ocefpaf @groutr @ilanschnell @insertinterestingnamehere - images are up on docker hub:

https://hub.docker.com/r/continuumio/conda_builder_linux/
https://hub.docker.com/r/continuumio/centos5_gcc5_base/

Again, the easiest way to use this image is with the scripts contained in this conda_builder_linux folder:
https://github.com/ContinuumIO/docker-images/tree/master/conda_builder_linux

docker_wrapper.sh is the main one you need. The others are for convenience so you don't have to remember which variables to pass in to change things. You can use this image interactively, or pass commands in through any of the scripts - they should all work.

I welcome feedback and hope this is useful to you. I will be working on getting these to be built by docker hub as much as possible. For the conda_builder_linux image, it should be possible. For the GCC base image, it is probably not possible due to time constraints.

[jjhelmus]

This is really great @msarahan. I'm a bit busy this week but hope to test out the Docker image next week and put together an image based upon it for use in conda-forge.

[msarahan]

Thanks @jjhelmus - if it makes more sense to have a more constrained image, you may want to start with the base image at https://hub.docker.com/r/continuumio/centos5_gcc5_base/ and layer on top of that. The conda_builder_linux image is aimed at making most (hopefully all) of the current internal conda recipes compile "out of the box." It includes things like gtk+, which eat up a fair amount of hard disk space. You may want to copy the startup scripts from the conda_builder_linux github repo, though.

As long as we all use a compatible base image, I'm excited for better compatibility across the ecosystem.

[insertinterestingnamehere]

This new toolchain is great. I've uploaded experimental builds of libdynd and dynd-python (both require C++14) and they appear to be working well everywhere I've tested them. They are available via conda install dynd-python -c iandh -c msarahan.

[msarahan]

@insertinterestingnamehere thanks for testing this. May I ask how you used the image, and whether you have any ideas for further improvement?

In terms of how you used it, I'm wondering whether people will find it best to:

1. pass arguments to mount code folders, and pass in build commands non-interactively (image is a sort of build-black-box)
2. interactively - clone software and build it at the interactive prompt
3. Somewhere in between?

[insertinterestingnamehere]

I did it all in the interactive prompt. That's plenty for me right now. An additional API seems like a reasonable thing to add at some point though. Perhaps a particular docker image to use could be specified as an option in meta.yaml? It's not entirely clear what the best way to manage getting the correct source into the contaner from there would be though. Some recipes may make assumptions about where they are located within the source tree of the original package, so there would have to be some way for a recipe to specify what its "root" source directory is.

[msarahan]

Here's an example (I've done this myself):

Let's say on my local computer, I have a recipe at ~/recipes/thing

I could do:

start_cpp98.sh -v ~/recipes:/home/dev/recipes conda build recipes/thing

and that should build the thing, and afterwards exit the container (I need to check if this also cleans up the container, which it should.) Anaconda build might do something like this to check out source only once, but build with different configurations of compiler (architecture and/or C++ ABI).

When you start talking about meta.yaml, that's more Anaconda build territory, IMHO - you're basically wanting different front-ends for driving the container?

[insertinterestingnamehere]

Well, my main thought is that, if we can automate running conda-build for a recipe, there's no reason to not allow people to tie a full build environment to a recipe if needed. It's pretty crucial information where things like libgcc and libc are concerned.
I don't see what you mean by a different front-end? Can you elaborate a bit more? My understanding is that we'd copy/mount the recipe and whatever directory it needs to the container and then run conda-build on the recipe while inside the container.

[msarahan]

Yeah, were on the same wavelength here, but I think what you're asking for
is extension of conda build to employ docker containers as work
environments. That's awesome, and we should do it, IMHO. But it's
separate from this build image (it just uses this build image, or any
other).

On Wed, Mar 30, 2016, 22:23 Ian Henriksen [email protected] wrote:

Well, my main thought is that, if we can automate running conda-build for
a recipe, there's no reason to not allow people to tie a full build
environment to a recipe if needed. It's pretty crucial information where
things like libgcc and libc are concerned.
I don't see what you mean by a different front-end? Can you elaborate a
bit more? My understanding is that we'd copy/mount the recipe and whatever
directory it needs to the container and then run conda-build on the recipe
while inside the container.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#20 (comment)

[insertinterestingnamehere]

Great! I'm glad we're thinking the same thing. You're right, that's definitely independent of the build image. I don't have much of an opinion on how we should interact with the build image until we get an interface like that set up.

[insertinterestingnamehere]

Another question here, what did you end up doing to let people choose between the GCC 5 ABI and the GCC 4 ABI?

[msarahan]

I set CXXFLAGS for them. You could set the CXXFLAGS directly if you want, but I find

ABI=4
or
ABI=5

more intuitive and less error-prone. The start_cpp98.sh script sets the former for you, while start_cpp11.sh sets the latter. Those get translated into the CXXFLAGS at https://github.com/ContinuumIO/docker-images/pull/20/files#diff-8320ce46adf2819c0900060bd6c14c43R16

[insertinterestingnamehere]

Got it. Is the plan still to use features to distinguish between packages with the different ABIs? Have those features already been set up somewhere or should I be managing that myself for now?

[msarahan]

I think we'll cross that bridge when we come to it. For now, limit
everything to the older ABI. If you have something that you need the new
ABI for, please communicate that need so we can understand it and factor it
into planning.

On Thu, Mar 31, 2016 at 3:47 PM Ian Henriksen [email protected]
wrote:

Got it. Is the plan still to use features to distinguish between packages
with the different ABIs? Have those features already been set up somewhere
or should I be managing that myself for now?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#20 (comment)