On Fri, Dec 2, 2016 at 2:08 PM, Raniere <[email protected]> wrote: > Hi Erik, > > Thanks for the good work! > > >>I hope to have a prototype ready soon for people to test out. But one >>question I have that's really bothering me is: Is there a *particular* >>reason we rely on Anaconda for our Python distribution in the lessons? > > Anaconda make easy to install some Python packages that require to compile > some C or Fortran code. For example, the lxml package requires the C library > that isn't installed by pip.
Yes, but this is generally a non-issue if using Cygwin. >> Is there something particular in the existing lesson plans that >>require Anaconda? > > How hard is to install matplotlib on Cygwin? Or AstroPy? We use Anaconda > because most of our learners will have the packages they need on their day > job out of the box. I figured that was the main reason. Most of these packages can install and work fine in Cygwin, but I would be worried about leaving something out and it might be a lot of additional effort to repeat the packaging that's already been done with Anaconda (as Maxime mentioned upthread this also includes SciPy, Pandas etc..) as well as things like scikit-learn. I can install most of these in Cygwin but to me the point of using Cygwin was *not* for Python per se, but all the other shell tools, where I think it excels over most other options (something based on MSYS2, itself based on Cygwin, might also be workable). On Fri, Dec 2, 2016 at 2:08 PM, Michael Sarahan <[email protected]> wrote: > IMHO, the nice thing about Anaconda is that it obviates a lot of the > integration questions. Having things in local environments makes life so > much easier that I can't imagine another way. > > Anaconda is huge, though. SWC could make a much smaller Anaconda-like > installer using constructor: https://github.com/conda/constructor - this is > also easy enough to maintain specific installers for each training, so that > the installers could contain only what was going to be used in a given > training. Instructors could create their own installer (just change the > input list of packages). Something like this might not be a bad idea either, but I think it's more orthogonal. If we do stick with Anaconda it might be nice to put together a smaller anaconda distribution on top of miniconda--this might also be easier for me to distribute in a single installable (and might even be fine to install for R workshops if it doesn't take up too much space). I'd like to also ease the tension between setup for R workshops and Python workshops by just including everything needed for both, but that's down the line... _______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/listinfo/discuss
