Skip to main content

2016-04-29

14:00 UTC

Hangout link: 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

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

    • 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

    *   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 and John Kirkham. 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) ).
  • 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 has rebuilt this.
    • John tested the image with a trivial C++11 program 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.