Thanks everyone for your encouragement. Full disclosure: I work for Continuum on the Anaconda build team. Any opinions I express here are my own, not those of Continuum, and you should not interpret anything I say as direction that Continuum will head in.
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. I will ponder this, and perhaps try to come up with a list of concepts that would need to be explained in either case, and choose the simpler route. 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. TLDR: Centralized distribution good, centralized recipes good, centralized recipe authority bad (but need peer review for QA). 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 On Sat, Oct 31, 2015 at 5:23 AM Filipe Pires Alvarenga Fernandes < [email protected]> wrote: > Hi there, > > I am also a +1 for this. I taught only one workshop, but conda made my > life a lot easier. Windows, OSX, and Linux people got a standard > environment for the class with little pain. All we had to do was to > install conda and distribute an environment.yaml. (The same > environment.yaml was used to create a binder [2] for those who could not > install anything in their laptop.) > > I maintain the IOOS channel and I am glad to help in this effort too. I > also want to mention conda-forge [2]. It is an effort to avoid effort > duplication and increase the collaboration in maintaining conda recipes. I > believe conda-forge goals are very similar to SWC lessons in that regard > ;-) > > [1] https://github.com/ocefpaf/intro_python_notebooks > [2] https://github.com/conda-forge > > Best, > > -Filipe > > >> Sounds like a great idea. Just for reference, there are a number of big >> conda recipe collection/metapackage efforts that might be worth looking at >> for examples of tooling involved in creating and building recipes: >> >> https://github.com/omnia-md/conda-recipes >> https://github.com/bioconda/recipes >> https://github.com/ioos/conda-recipes >> >> I also maintain my company’s internal conda metapackage, so I’d be happy >> to help out if I can. >> >> Josh >> >> On October 31, 2015 at 12:18:24 AM, Michael Sarahan ([email protected]) >> wrote: >> >> OK. Two thumbs up means get started. >> >> A repo in the SWC github org is probably where the swc-* metapackages >> belong. Please do make a repo for me. For recipes I'm building out that's >> more general purpose (git for windows, nano), I'm planning on keeping them >> at conda-recipes. >> >> Org is up https://anaconda.org/swc; I added you (jiffyclub) to the >> owners. >> >> Link coming soon, over the next couple of days. >> >> On Fri, Oct 30, 2015 at 10:59 PM Matt Davis <[email protected]> wrote: >> >>> This sounds like a really neat idea, go for it! I'm interested in >>> helping with the org. Do you want a repo in the SWC github org to store the >>> package metadata? >>> >>> Please let us know how it goes and link us to your >>> instructions/materials when they are up. >>> >>> - Matt >>> >>> On Fri, Oct 30, 2015 at 5:23 PM Michael Sarahan <[email protected]> >>> wrote: >>> >>>> Would anyone object to me creating an Anaconda.org organization for >>>> SWC? I would like to build packages and put them there so that during >>>> setup, people can basically do: >>>> >>>> (install miniconda) >>>> conda install -c swc swc-python >>>> >>>> where the -c swc would be the channel, and swc-python would be a >>>> metapackage that I'll create to pull in Python, nano, git, etc. as >>>> necessary - basically a one-stop shop for any platform. There could be >>>> other metapackages, perhaps swc-python, swc-r, or whatever. This runs >>>> parallel to the swc installer ( >>>> https://github.com/swcarpentry/windows-installer), but might be >>>> simpler, since one could customize metapackages based on what kind of >>>> course was being taught. >>>> >>>> If no one objects, I'd like to do this this weekend in preparation for >>>> my teaching this week. I'm also happy to add other SWC folks to the >>>> organization to help with upkeep and to add stuff. Just reply to me >>>> offline. >>>> >>>> Let me know... >>>> Mike >>>> >>> _______________________________________________ >>>> Discuss mailing list >>>> [email protected] >>>> >>>> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org >>> >>> _______________________________________________ >> Discuss mailing list >> [email protected] >> >> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org >> >> >> _______________________________________________ >> Discuss mailing list >> [email protected] >> >> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org >> >
_______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
