> > Filipe, thanks for pointing me to the environment.yaml. I'm pretty new to > that approach, but it is nice in that people don't really have to know > about channels in order to get set up. That's sort of hidden in the > environment.yaml. The downside is that they have to "activate" an > environment created that way - so you have to teach them about environments. >
Conda or no I encourage teaching the concept of environments. I always bring the reproducibility discussion to the table when teaching. Also, I noticed students fell good that they can easily remove and re-create envs. New students are sometimes afraid of messing up the installation. I think that the env concept takes that fear away. > I am vaguely aware of conda-forge, and I have high hopes for it. The > repositories that Josh posted both impress and terrify me. A large amount > of work has gone into each of them - work that may be duplicated across > many of these kinds of repositories. If people are re-creating similar > recipes, there's a reasonably high chance of incompatibility when it comes > to shared library versions and compilation options. That's fine if people > are going to just stick to one channel, but could become a mess very > quickly as more channels are included. > > I am left pining for a better centralized recipe host, along the lines of > CRAN, CPAN, or to a lesser extent, PyPI. I think the conda-recipes github > repository has failed in that regard. I think the main reason it has > failed is that it does not provide a route for authoritative maintenance of > a given recipe, nor any route for built packages to be made available on a > central repository (OK, anaconda.org **kind of** counts, but having to > select a channel takes it sideways.) As promising as conda-forge is, I > don't think it helps solve this authority problem (yet?) - it still relies > on rather centralized control over a global set of recipes (feedstocks), > although it does greatly improve the centralization of build and > distribution. > We discussed these issue a lot at Scipy2015. But let's not hijack this thread going back to that. (However, we must talk about this somewhere else until we find a better way to move forward. The community is eager to find a better way to create and maintain recipes and I think you have a very clear understanding of the problems we are facing.) > TLDR: Centralized distribution good, centralized recipes good, centralized > recipe authority bad (but need peer review for QA). > Until something better gets momentum (conda-forge ;-) I am +1 too all that. Thanks for the discussion. Please continue further discussion at the > relevant github issue: https://github.com/conda/conda-recipes/issues/441 > > I'll post back here with what I come up with for the workshop - probably > not a final solution to the problem (what is final?) but hopefully it will > work. > > Best, > Michael >
_______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
