# 2016-04-29 14:00 UTC Hangout link: [](https://hangouts.google.com/call/v5olhwzpfzgzpoq5i3wthjpqpie)https://hangouts.google.com/call/v5olhwzpfzgzpoq5i3wthjpqpie Agenda: * Dependency tracking (I know this has jumped the order, but this has become extremely pressing.) * Proposed fixes to conda-build. There are many and this is pretty slow moving. * Question about conda-smithy/conda-build-all requirements. Please see reference to "Question 4.5" in [this comment](https://github.com/conda/conda-build/pull/848#issuecomment-215523101) * Internal pinning mechanism. [Phil Elson](https://conda-forge.hackpad.com/ep/profile/AviM60TiesB) wrote some nice scripts here and they are very helpful. * Questions: * How can we figure out what things need pinning? * When do we rollback a pinning? * How can we handle pinning in a more automated manner? * What things should be pinned? * How to handle version updates? * How to identify problem areas (packages that can't accept a pin)? * PyPI metadata redundancy * Prototype tool to convert pure Python wheels directly to conda packages: [](https://github.com/takluyver/wheel2conda)https://github.com/takluyver/wheel2conda * Automated feedstock maintenance. * Python3 vs Python==3 * How to depend (inc build depend) on applications which require Python 3, from a Python==2 env * 'Subenvironment dependencies' are a possible alternative * Complex licenses (e.g. MKL, CUDA, cuDNN, etc.) * Packaging python itself * VC features (what more needs discussing for the general meeting?) * yum requirements (partially resolved) * Low level packaging * NetCDF (also curl/ca-certificates and Perl packages) * Adding a devtoolset to the container (for now). * Movement of Docker images to common spaces (Docker Hub org, GitHub org). * MSYS2 integrated into conda. How do we want to use this? Do we still want VC? * GitHub rate limitations. How can we further mitigate these? * Add namespace to packages `node-`, `ruby-`, `perl-`, `why not python-` ;-) * Dropping py34 [conda forge/staged recipes#465](https://github.com/conda-forge/staged-recipes/pull/465) Notes: * Let's give webex a shot * Dependency tracking * Currently baking in versions into the recipe, automated with script from [Phil Elson](https://conda-forge.hackpad.com/ep/profile/AviM60TiesB) * Version choices are decided manually at the moment * [](https://github.com/conda-forge/staged-recipes/wiki/Pinned-dependencies)https://github.com/conda-forge/staged-recipes/wiki/Pinned-dependencies * What if we want to change a pinned version, say zlib 1.2 to 1.3? * Shared VM which performs automated and semi-automated tasks which multiple contributors have access too * Look into setting up a lightweight host/VM, heroku * How to decide when to update pinned dependecy * Proposed fixes to conda-build, [conda/conda build#848](https://github.com/conda/conda-build/pull/848) * Will these brake conda-build-all, do we care? * Micheal is working on conda-render tool to try to fill in as much jinja template as possible * Talk about this specific topic, plan agenda in advance * Plan time using emai/GitHub * Sticking point are build matrix and validiatable * Complex licensing, ie MKL, CUDA, CuDNN * MKL runtimes are spelled out, headers more complex * CUDA seems better, CentOS 6 images available * Micheal not aware of CuDNN requirements * Micheal will look into cuDNN license constraints. * Python package * Windows needs some files moved. * Features or vc package? * xz 5.0 or 5.2? Start with 5.0, then do 5.2 build * Branding? * Easy to implement, but is it wanted? * Not major concern for Continuum * Helpful when resolving problems, detecting when system Python * Put it in, not too hard and will help downstream organizations All of the contents below were discussed between [Phil Elson](https://conda-forge.hackpad.com/ep/profile/AviM60TiesB) and [John Kirkham](https://conda-forge.hackpad.com/ep/profile/wv6uvIZX6h0). Many of the items have already been planned before and just need the details ironed out. Anything that required large group discussion was not decided in anyway. * Yum requirements * Decided to go with this PR ( [conda forge/conda smithy#135](https://github.com/conda-forge/conda-smithy/pull/135) ). * Current use case is still VTK and freeglut (forgot to mention this). Though VTK is proceeding through a new PR ( [conda forge/staged recipes#453](https://github.com/conda-forge/staged-recipes/pull/453) ). freeglut is still in this PR ( [conda forge/staged recipes#373](https://github.com/conda-forge/staged-recipes/pull/373) ). * Low level packaging * Some brief discussion about using different subchannels for these to avoid dependency clashes (e.g. compiler components). * There are some gray areas that will eventually be encountered, but no examples were fleshed out. Though a few might be `gmp` and `mpfr` as they are both compiler dependencies and used by other packages like symbolic math packages (e.g. SymPy). * Adding a devtoolset to the container (for now). * This was already merged (adds devtoolset-2). * [Phil](https://conda-forge.hackpad.com/ep/profile/AviM60TiesB) has rebuilt this. * [John](https://conda-forge.hackpad.com/ep/profile/wv6uvIZX6h0) tested the image with a trivial C++11 [program](https://github.com/jakirkham/hello_tests/blob/5b2f6b0c5682ecd84bee3be9cb73d790265f6002/hello.cxx) and that worked fine. * Automatic builds are not working. Will likely contact Docker to fix. However, this only matters if this problem still happens after moving the images. * Movement of Docker images to common spaces (Docker Hub org, GitHub org). * [John](https://conda-forge.hackpad.com/ep/profile/wv6uvIZX6h0) will add the PRs to move Obvious-CI's Docker image to the org and from Obvious-CI. * Docker Hub org is already setup * Repo on GitHub is ready to go. * Need to setup autobuilds for the image(s). * Also, need to switch everything to using the Docker image from the org repo.