linux-32 builds

[AbdealiLoKo]

From @AbdealiJK on May 24, 2016 9:21

It would be nice to have 32bit builds in Linux. Right now, only linux-64 is there https://conda.anaconda.org/conda-forge

This way linux-32 packages would also be created when submitting to conda ?

Copied from original issue: conda-forge/conda-smithy#183

[AbdealiLoKo]

Apparently travis doesn't support 32bit nor has a plan in the near future to do so - travis-ci/travis-ci#5770
So I guess it can be done by cross compiling (Installing a 32bit conda), or using a 32bit docker image

[AbdealiLoKo]

From @pelson on June 1, 2016 8:26

Hi @AbdealiJK. Thanks for submitting this issue. Whilst the changes would involve conda-smithy, we would normally discuss this in the conda-forge/conda-forge.github.io repo. Interestingly we haven't discussed 32bit linux builds there yet, but it did come up in one of the feedstocks at: conda-forge/eofs-feedstock#1

As I said in that issue, I have been a bit surprised about the lack of demand for linux-32 builds. There are clearly some people who want it, but it isn't clear that the effort needed to implement it outweighs the benefits.

Technically, I'm pretty comfortable that linux-32 builds are completely achievable with CI (circle + docker gives you a lot of power).

Perhaps you can bring this up as an issue on https://github.com/conda-forge/conda-forge.github.io/ and if interested join us for a future conda-forge developer hangout (there is one this Friday, but I'm aware the agenda is already quite full, so maybe the one after).

Cheers,

[AbdealiLoKo]

From @jakirkham on June 4, 2016 6:9

I know @rgommers mentioned some interest in this as well at one point.

[AbdealiLoKo]

From @rgommers on June 5, 2016 10:23

I did, but there's not a lot of demand so I agree with @pelson that the effort/benefit tradeoff here isn't clear. The main reason I'm using it is to catch issues not found on TravisCI for Numpy and Scipy.

[patricksnape]

Surely if we wanted 32-bit builds we would use a 32-bit docker container on circleci?

[AbdealiLoKo]

I mainly wanted linux-32 because I happen to be using a laptop with 32bit, and can't install conda-forge packages easily because of that.
I agree with @rgommers that there's probably very low demand for linux-32, and if its not easy to setup, it should be avoided.

@pelson Sorry about creating the issue in the wrong place ^^ Moved it now.

[msarahan]

We have 32-bit builds in the Continuum docker container (https://hub.docker.com/r/continuumio/conda_builder_linux/). This is done with gcc that is built to compile both 32-bit and 64-bit code.

It's not 100% working. Things look many places for whether to build 32-bit or 64-bit, and we have not isolated all of them. It does work for many cases, though.

It might be simpler to just have a separate docker image for 32-bit, as manylinux does.

[frol]

At Salford Systems, we have been building conda packages for x32 and x64 Linux using separate Docker containers (namely, toopher/centos-i386:centos6, and centos:6) on x64 host system for over a year with no issues at all. Today, even though I have contributed our packages to conda-forge, we still have to build those feedstocks ourselves only because of the lacking linux-32 support.

[ocefpaf]

@frol the demand for Linux-32 is low mostly b/c people don't report it here. I see a continuous increase of Linux-32 downloads in the old IOOS channel that worries me. (Although part of those downloads were explained to me last month and were due to a docker image that people were passing around.)

I would love to see conda-forge building those, but we are lacking CIs (and man) power.

Right now we use CircleCI for the Linux builds and Circle does not support a build matrix, correct?

We could use another docker image and an add an extra item to the Travis-CI matrix, but Travis-CI is already showing signs that it won't scale to our current needs.

So before we do that we need to think how we can get more CI power/speed.

[frol]

@ocefpaf I do understand that x32 platform requires extra resources and has lower importance. I would love to see building x32 packages only when CIs are not busy with other platforms. ARM platform is just another similar use-case.

As to the CIs power, it makes a lot of sense to me to pay more attention to the performance of the preparation scripts and conda itself.

[jakirkham]

Right now we use CircleCI for the Linux builds and Circle does not support a build matrix, correct?

Correct. There are some builds that already are at the limit of CircleCI's build time. Adding 32-bit support is currently not practical. These include pretty basic things like scipy, which will block progress on most other things.

[ocefpaf]

These include pretty basic things like scipy, which will block progress on most other things.

I don't think that is a blocker as scipy itself is a new recipe in conda-forge and there is always the default channel scipy. If we think like that we'll never do it.

My point in #163 (comment) is just to bring awareness that, with more CI and man power, we can (and IMO we should) do it.

[jakirkham]

It was merely one easy example. The point is we are extended or overextended in terms of resources in some cases. If we had more resource, of course, it would be possible to consider this.

Personally, I still don't understand the use case for 32-bit. Could someone please explain to me when this is helpful? Is it only for legacy machines or is there some other particular use case that I'm unaware of? I admit ignorance here; so, if there is a useful case please simply explain it. If it is former, I think like some others things (e.g. OSes) we have decided that there is some minimum level system that we can support practically. Currently 32-bit is in the same boat IMHO.

[jakirkham]

I should clarify that my confusion is about the purpose of 32-bit Linux. I'm a bit more aware of the situation (though maybe not as intimately familiar as others) on Windows. Also, as we don't support an old enough OS on Mac, we have already accepted that 32-bit support doesn't exist there.

[msarahan]

@frol,

As to the CIs power, it makes a lot of sense to me to pay more attention to the performance of the preparation scripts and conda itself.

This is a very good point. Conda and conda build could really use some optimization love. Just importing conda on Windows takes 2.5 seconds on my computer, as measured with time python -c "import conda". Conda build's test suite currently takes about 2000 seconds to complete on my Win 10 VM.

We'll get there, but we're very tied up with other capabilities that we think are more important than speed: namespaces on the conda side, and build customization and python API on the conda-build side.

If anyone has ideas to speed up either conda or conda-build, I'd be very excited to discuss them.

[brian-rose]

Hi all, just found this discussion about linux-32 builds on conda-forge.
Apparently there is demand for a linux-32 build of the climlab package, because I just heard from one of my student-users trying to install on Xubuntu 14.04.5 (a 32-bit linux distribution).

I will probably tell this particular user to try to build directly from source, but I just wanted to add my +1 for linux-32 builds.

To @jakirkham, the use case here is a student coming in with their own laptop and wanting to participate in a course that uses climlab. I expect it's a fairly uncommon case. The vast majority of my users are on Mac or Windows. Of those who are on Linux, I really don't know how widespread is 32-bit.

[goanpeca]

@jakirkham why not use parallel builds (on circle ci) so that the setup phase selects the right docker and then the run commands will ran in parallel on the respective docker image?

[jakirkham]

We looked into that for just getting parallel builds going for Python and NumPy versions with CircleCI some time back. However this is not exactly trivial as there is no way to setup a matrix like one does with Travis CI and CircleCI. Even once one splits up a parallel build to use a matrix, the CircleCI GUI is not great at clarifying what a build is parameterized with. We can probably hack in some environment variable echoing step, just it will be a little ugly to use. Not to say it wouldn't be worth the effort, just no one has had time to pursue this. If you have cycles to spend on that effort, this would be a really great contribution for the community.

That said, I'd be of the opinion that any matrix build like feature on CircleCI would be better spent splitting out existing builds that are going over the time limits and already require ugly hacks (e.g. scipy, scikit-learn, vtk, etc.). Once we have done that, we can certainly reevaluate 32-bit Linux builds. However I expect doubling the wait time, which will have increased due to parallel builds saturating the queue and our 4 available workers, will be somewhat controversial. There might be ways to mitigate that by making matrix builds optional or making use of noarch Python builds for instance.

Would add that even 32-bit Windows builds see dramatically less usage compared to 64-bit Windows builds. In fact, I venture to guess that a substantial amount of the traffic for Windows 32-bit builds is simply a consequence of downstream dependencies on conda-forge and not actual use. Would imagine it is a matter of time before the discussion is raised that we should drop 32-bit Windows builds to speed up the AppVeyor queue.

[goanpeca]

@jakirkham I guess I meant something along these lines:

machine:
  environment:
    # Docker images
    DOCKER_IMAGES: "condaforge/linux-anvil condaforge/linux-anvil-32"

general:
  branches:
    ignore:
      # We only want to build pull requests for testing. If something is merged,
      # then we are prepping for release and there is no need to build it again.
      - master

checkout:
  post:
    - ./scripts/fast_finish_ci_pr_build.sh
    - ./scripts/checkout_merge_commit.sh

machine:
  services:
    - docker

dependencies:
  # Note, we used to use the naive caching of docker images, but found that it was quicker
  # just to pull each time. #rollondockercaching
  override:
    - export DOCKER_IMAGES=($DOCKER_IMAGES) &&
      export DOCKER_IMAGE=${DOCKER_IMAGES[$CIRCLE_NODE_INDEX]} && 
      echo -e "DOCKER IMAGE USED = $DOCKERIMAGE" &&
      "docker pull $DOCKER_IMAGE";

test:
  override:
    - ./scripts/run_docker_build.sh

[jakirkham]

Right something like that could work if we enable just 2 concurrent builds. Though there would be a (minor) change to scripts/run_docker_build.sh as well. We would also want to echo info about which image is used somewhere. Plus we need an API to enable parallelism so that conda-smithy can do this to existing and new projects. I don't recall their being one provided by CircleCI last time I looked, but there may be an undocumented way to do this.

Then there is the issue of creating and maintaining the 32-bit Docker image. Certainly doable, but it does raise a question regarding upgrading the devtoolset compiler, which has come up before due to interest in C++14 support. ( conda-forge/docker-images#22 ) ( conda-forge/docker-images#23 ) IIRC devtoolset-2 was the last version to have 32-bit and 64-bit support. The devtoolset-3 and devtoolset-4 compilers were 64-bit only, again IIRC. This raises more questions when things like CentOS 6 and devtoolset-2 reach their EOL.

There is a bit of a resource issue with CircleCI though. After all CircleCI only gives 4 concurrent builds. In general these slots would be really handy for long running builds, which already have kludgy workarounds that are burdensome for maintainers. More often than not these are very popular packages in conda-forge (e.g. VTK, OpenCV). If we use 1 of our concurrent builds for 32-bit Linux, it blocks us from using them for say 3 Python versions (as this would require 6 concurrent builds with 32-bit Linux) or requires that we get these 2 other builds somehow (asking nicely and/or paying). We could do 2 NumPy versions, but that doesn't solve some cases like vtk.

It might be ok if we used a different CI provider for the 32-bit builds and we accept that the compiler used by 32-bit may differ from the one for 64-bit in time. Though it does make it feel like we are working pretty hard to support legacy systems that is falling out of use. Might be worth the effort if some use cases came to the forefront that were not going to just disappear.

[jakirkham]

It seems this issue has gone stale. Closing it out.