Hi, On Thu, Jan 9, 2014 at 10:48 PM, Aaron Meurer <asmeu...@gmail.com> wrote: > On Thu, Jan 9, 2014 at 4:39 PM, Matthew Brett <matthew.br...@gmail.com> wrote: >> Hi, >> >> On Thu, Jan 9, 2014 at 7:16 PM, Aaron Meurer <asmeu...@gmail.com> wrote: >> <snip> >>>> Have the authors of conda gone on the distutils mailing lists to >>>> advocate conda as a solution to the distutils problem? >>> >>> A lot of conda is built around the frustration of the bad design >>> decisions of distutils plus the inability for the community to really >>> understand the needs of the scientific community, so conda works more >>> or less around distutils (the build stage works on top of distutils, >>> if you want, but the install stage works independent of it). >>> >>> To answer your question, I'm not sure what direct advocation has been >>> done, but the core packaging guys are definitely aware of conda. >> >> Yes, that was my impression. >> >>>>> In fact, a lot of people are starting to use conda (either using >>>>> Anaconda or separate from it), because it really solves these problems >>>>> (this includes people at Berkeley). >>>> >>>> I may not be talking to those people for some reason :) >>>> >>>>> The great thing about Anaconda (the distribution) is that it comes >>>>> with things that really enhance the SymPy experience, like the IPython >>>>> notebook, matplotlib, the IPython qtconsole (which is a serious pain >>>>> to install from source even on Mac OS X), numpy, scipy, and so on. We >>>>> have to remember with SymPy that we are part of the SciPy stack >>>>> (http://www.scipy.org/about.html). >>>> >>>> Yes, I teach using a lot of that stack, so I too need all the >>>> dependencies installed. We agree that Anaconda is convenient, but >>>> may be we disagree about the potential risks to the ecosystem. >>>> >>>>>> >>>>>> I'm not suggesting that we deprecate the large installers, but only we >>>>>> be careful to make sure that other options exist. >>>>>> >>>>>> I'm happy to do the extra work over the hour needed for sympy release, >>>>>> to generate the windows installers, and test them. >>>>> >>>>> The issue is that I really want it to be possible to make the entire >>>>> release by myself, whenever I want to. Far be it from me to turn away >>>>> help, but the kind of help that actually isn't helpful is to say, >>>>> "sure, I can help you do that whenever you do a release. Just ping >>>>> me". >>>> >>>> Well - you plan to do the release without the windows installers. So, >>>> why not - do the release without the windows installers - and then >>>> >>>> a ) ping me to upload the windows installers OR >>>> b) let me set up an automated system to build the installers on our >>>> buildbots and you can upload those after triggering the build on the >>>> web and downloading the built installers to your machine. >>>> >>>> There's no need for the windows installers to arrive at the same time >>>> as the source installers is there? Why not leave the binary >>>> installers as pleasant extras on pypi to be uploaded when ready. >>>> That's what the matplotlib guys have done for the last release, for >>>> example (for OSX). >>>> >>>>> And it isn't you personally. I don't want the release to become >>>>> dependent on *any* one person, myself included. That's why I worked so >>>>> hard to make the whole release process automated, so that it can be >>>>> reproduced by anyone (with the caveat that I'll need to give you >>>>> access to PyPI if you want to do it, but I'll do that for any core >>>>> developer who volunteers to do a release). >>>> >>>> As you can give access to pypi, I can give access the buildbot >>>> machinery, or set up the machinery to do the work automatically. The >>>> buildbot stuff is all on github, so it would not be very hard to set >>>> up your own buildbot farm if you don't want to use ours. I agree >>>> completely that it's good to automate the process and make it easy to >>>> pass on - we had the same idea when setting up the buildbots. >>> >>> I suppose if you want to set that up we can support it. Are these >>> buildbots capable of testing the installers so that we can be sure >>> that they work? >> >> Yes - they build the installer and then install it into a virtualenv >> and run the tests before uploading to a public web directory. Here's >> one example: >> >> http://nipy.bic.berkeley.edu/builders/nibabel-bdist32-32/builds/49 >> >> It sounds like a plan. I'll set those up. >> >>>>> By the way, just to be clear of something, are you requesting the >>>>> Windows installers, or just offering to help make them? I'm not asking >>>>> to discredit you, but simply because if you do, that's an argument to >>>>> do it (because as I noted earlier, if enough people request it, I >>>>> could be convinced). >>>> >>>> You're asking because, if I do not myself want the installers, the >>>> offer of help is not useful? >>> >>> No, again, not trying to discredit you or anything. Just trying to >>> tally a vote :) >>> >>>> >>>> Yes, I want the installers, because I'm going to do more classes this >>>> year and I want my students to be able to do default installs of Sympy >>>> - because I use it all the time and I want them to use it to - as I do >>>> for the teaching notebooks. >>>> >>>> As a short thank you note, sympy has made a big difference to teaching >>>> because it's made it so much easier to integrate symbolic mathematics >>>> and numerical code. So, for my teaching, I want installing sympy to >>>> be as trivial and obvious as possible. "Go to pypi, download >>>> installer, run it". >>> >>> Well, you can't argue that if your top priority is to make things as >>> easy as possible for your students, then "install Anaconda" is the >>> simplest possible thing you can tell them, especially if you want to >>> include more than just SymPy. >> >> I want my students to leave with a system they will continue working >> with and building on, so it is OK with me that this isn't one-click. >> >>>> But - for the sake of the whole ecosystem - I want to avoid *having >>>> to* depend on the monolithic installers. >>> >>> SymPy is the last thing that will have to depend on Anaconda, because >>> it's pure Python, so building is not difficult. The "depending" is >>> more of an issue for compiled packages, where building, especially on >>> Windows, can be hugely painful. >>> >>> If the monolithicity is an issue for you, you can just install >>> Miniconda (http://repo.continuum.io/miniconda/) and install just what >>> you want. >> >> It sounds like we have a way forward with the buildbot installer >> builds then. I'll get onto that very soon. > > Thanks. Let me know when it's ready, and give me the email I should > give access to PyPI.
OK - will do. > Should we also upload these to GitHub? We don't > have to if you don't want to do the work with playing with the API > (though I've already figured out how to do it if you look at the > release fabfile). Huh - I hadn't seen that machinery on github - I'll look into that. > Also tell me where the code is in case I need to > make any pull requests or check on anything. It will be in https://github.com/nipy/nibotmi > Regarding me pinging you, is there a way to automate that as well > (i.e., the release script just pings the build server somehow)? Yes, it looks like this is possible. You wouldn't need to ping me in any case, you can trigger builds from the web interface as well. I'm just debugging a release for another project at the moment, I will get to this as soon as I can. Cheers, Matthew -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
