Skip to main content

2016-05-13

14:00 UTC

Hangout link: https://hangouts.google.com/call/v5olhwzpfzgzpoq5i3wthjpqpie

Attendees

  • Jonathan Helmus
  • Michael Sarahan
  • John Kirkham
  • Phil Elson
  • Eric Dill
  • Anthony Scopatz
  • Filipe Fernandes

** Agenda**

  • PyPI metadata redundancy
    • Prototype tool to convert pure Python wheels directly to conda packages: https://github.com/takluyver/wheel2conda
    • Automated feedstock maintenance.
    • URL to use for source. (this is kind of tied in with this so I added it here. though a longer topic is present for it below, "Link preference with packages...".)
  • 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
  • Low level packaging
  • NetCDF (also curl/ca-certificates and Perl packages)
  • 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-` ;-)
    • 'Practicality beats purity' ;-)
    • At least at first, but i don't find this generally true.
    • One of the things proposed at continuum is the notion of primary namespaces - ones that effectively defined a default prefix of the namespaced for the package. This might be the best of both worlds. You could have ordered priority, too: search python-* first, then node-* next, then finally the full package name with no prefix. This priority would be defined by per-environment condarc perhaps, with initial saying depending on what packages get installed. For example, creating an env with python installed first would make python primary env.
    • I can understand the attraction of that, but it seems like a potential source of considerable confusion (e.g. why does installing x work differently in this environment to that one?). Maybe this would be more workable if namespaces were actually part of a new syntax, rather than just prefixes on package names.
    • Sure, that's reasonable - have the namespace search thing be a user-defined convenience thing, rather than an automatically determined thing.
    • It is worth keeping in mind that the Python naming change would be a big break from existing Continuum packages. So, this decision should not be taken lightly.

  • Another thing to consider here might be a new piece of metadata. For instance, we could specify the primary language of a package. We could then specify to conda install that we want this language of a package. Possible syntax might include something that looks like that of the above. Not sure how we want to handled conflicts if we want to error, warn and install everything, or something else.

  • Dropping py34 conda forge/staged recipes#465

  • Link preference with packages options below:

    *   Prefer close to source (e.g. GitHub tarballs)

    • Package management sites (e.g. PyPI)

          *   No matter where the source lives an installable package will be on PyPI.

      • Easier to incorporate into automated maintenance (however we do that).

      • Sometimes includes important pre-build steps.

      • Avoids any rate limiting that a GitHub download might incur.

      • Avoids redoing any steps that developers have done for us.

      • Other options?

  • Celebrating supporters

    *   Some supporters

            *   AppVeyor
    *   Continuum
    *   Others?

    *   Splash page like Jupyter has? Something else.

  • Variants. ( conda forge/staged recipes#525 )

  • PR reviews

    *   Treat every PR as a Work in Progress. At least let PRs sit for a few hours before merging them.
    • Wait for answers when we ask clarification questions and avoid acting before we have them.
    • Respect the first reviewer by not repeating her/his review comments with another words. That is also bad for the person submitting the PR as it is confusing.
    • Avoid the death by a thousand cuts: Many small "nit" comments that might scare new contributors ( ping Mike S ;-)

  • Community presence.

    *   Twitter ( [conda forge/conda forge.github.io#114](https://github.com/conda-forge/conda-forge.github.io/issues/114) )

  • Standardization of toolchain configuration ( conda forge/staged recipes#578 ).

** Notes**

  • Next meeting, have one next week?

    *   Wednesday/Thursday, 1400 UTC

  • New release of conda-build coming, recipe is in the works and will be submitted soon.

    *   cmake has issues with VC2008 express, AppVeyor.yaml may need to be updated

  • Celebrating supporters

    *   Splash page, networkx widget to show who is contributing
    • Monetary support, have been approached by NumFocus
    • Needs someone (?) to do some web design for page on logos

  • Dropping py34 conda forge/staged recipes#465

    *   Requires move to VS2015, mingw-64 still has issues
    • ~50% of Python 3 users are 3.4
    • Python 3.6 final is to be released in 12/16/2016
    • Would be fine to support only 2.7 and 3.5
    • What do download counts show? Issues with CI consuming
    • Drop 3.4 when Python 3.6 is released

  • req = urllib.Request(url, headers={'User-Agent': 'Mozilla/5.0'})

  • https://github.com/pyne/pyne/blob/4ddb759afce46e278d8f8a79fc4b96d58334d0a2/tests/utils.py#L20

  • Mirror tarball as a release in the feedstock repository

  • Variants.

    *   Use features, end up making meta-packages, pain to maintain

    • BLAS variant package?

    • Have multiple branches on Numpy, each would have a different BLAS variant, maybe even play with build matrix to simpify.

    • Michael more interested in sub-environments.

    • How would these interplay with the packages provided by defaults?

          *   Don't use features? Would this work?  Solved may be trying to minimize number of features, needs some testing.
      • Likely best solution for short term, longer term it would be nice if conda/conda-build supports this.

    • For time being use OpenBLAS for NumPy build

    • Messes with the build string, no build number

  • Community presence.

    *   Twitter, set up twitter bot to post about when packages get added... which ones?

    • Stack overflow. Should we be monitoring SO to recommend and help folks with conda-forge.

          *   Anthony will add Google alerts to monitor, other should also
      • Others should considering doing this too.

  • Phil has script to re-render feedstocks, but currently only he can execute.

    *   Set up Heroku account which run this

    • Can select feedstocks be re-rendeded? PR needed for this feature

    • Sometimes connection to anaconda fail, especially on AppVeyor.

    • Maybe need a better error message from AppVeyor

    • appveyor cache info: https://www.appveyor.com/docs/build-cache

          *   "Resulting archive should not exceed 100 MB."

  • Conda-forge presentation slides from Filipe for SciPyLA

  • Next meeting in three weeks, Friday June 3, 1400 UTC

  • Merging PR from staged-recipes

    *   `make check`

  • Adding people to have rights on staged-recipes will be decided upon each meeting.