Skip to main content

2016-04-15

How to manage agendas & meetings?​

use hackpad for agenda, repo for minutes

Agenda hackpad: https://hackpad.com/conda-forge-meeting-notes-WZIa4PBQ6sz

Stats on conda-forge​

google analytics says 500 unique visitors to conda-forge Packaging 300-ish feedstocks in conda-forge 600-ish packages at continuum

1126 packages on conda-recipes (918 non-r), though some are repeats (e.g. python2 vs python3)

import os
packages = [f1 for f1, f2, f3, in os.walk('conda-recipes') if 'meta.yaml' in f3]
print(len(packages))

$ find . -name "meta.yaml" | wc -l
    1126

Next meeting​

2016-04-29 14:00 UTC

External developers to github.com/continuum repos​

In particular, the heroku build pack. https://github.com/conda-forge/conda-forge-webservices is using neither the Continuum one, nor the one written by the Heroku product owner.

No precedent for non Continuum contributors yet. We would love to have a canonical conda buildpack.

Centos5 vs Centos6​

conda and conda-build are hopefully to be upgraded to understand the glibc version

conda will be upgraded to provide analytics to anaconda.org on the glibc version of the requestor to feed information about the systems people are installing onto

Suggested that one standardizes the syntax on the build commands, not the images that are used to build

Features and feedstocks​

figuring out how you select a library that implements a common features set

  • single repo for numpy and use selectors/features/branches to control how things get built
    • mild-preference for single repo with selectors to toggle

NetCDF​

Q: How should we manage multiple "features" within it (e.g. compiled with/without OpenDAP)

If possible, build as much as possible, but only provide the sensible run-time dependencies. Adding further dependencies would enable more functionality.

In practice, that is sometimes not possible (e.g. a required .so is missing), in which case, we will need to be able toggle different build "variants". @msarahan suggested that the conda features concept may not be the best way of solving this.

Windows VC feature​

There is no strong candidate for going forwards at this point. Suggestion is to investigate some more, and @msarahan, @jakirkham and @pelson to reconvene on 2016-04-22 at 14:00 UTC (though previously advertised for the 21st) to discuss specifically this issue.

  • Features are intended to standardize packages that need certain things across your installed packages

  • if you install a package that tracks the vc9 feature and one that tracks the vc10 feature and both get installed, conda will fall over and forget how to resolve dependencies and both will get installed?

  • vc## features should never be added as a runtime requirement?

Documentation​

add a folder in the conda-forge.github.io git repo

A: John to add guidelines

Next planned meeting is 2016-04-29 at 14:00 UTC