On Thu, Jan 9, 2014 at 6:03 AM, Matthew Brett <[email protected]> wrote: > Hi, > > On Thu, Jan 9, 2014 at 12:18 AM, Aaron Meurer <[email protected]> wrote: >> On Wed, Jan 8, 2014 at 5:07 PM, Matthew Brett <[email protected]> >> wrote: >>> Hi, >>> >>> On Wed, Jan 8, 2014 at 7:07 PM, Aaron Meurer <[email protected]> wrote: >>>> On Wed, Jan 8, 2014 at 10:25 AM, Matthew Brett <[email protected]> >>>> wrote: >>>>> Hi, >>>>> >>>>> On Wed, Jan 8, 2014 at 3:57 PM, Aaron Meurer <[email protected]> wrote: >>>>>> This Windows installer is problematic. We are not really able to test >>>>>> it. I think we should probably stop making it. For one thing, it >>>>>> doesn't work everywhere (e.g., you can't make a 64-bit installer >>>>>> unless you are using Windows). If there is interest, I can try to >>>>>> debug and fix it, but otherwise, I think we should just stop making >>>>>> them. >>>>>> >>>>>> My recommendation to anyone installing on Windows is to just use >>>>>> Anaconda. See http://docs.sympy.org/latest/install.html#anaconda. >>>>>> That will just work, and if it doesn't, Continuum has the resources to >>>>>> fix the problem. And it comes with a bunch of other stuff like the >>>>>> IPython notebook and matplotlib that you might find useful when using >>>>>> SymPy. >>>>> >>>>> Did y'all try the installer at http://www.lfd.uci.edu/~gohlke/pythonlibs/ >>>> >>>> Yes, I forgot about the Gohlke installers. This was is preferred if >>>> you already have Python installed and you want to install into it. >>>> Note that your Python has to be registered in the Windows registry for >>>> these installers to work (and probably for the ones we currently ship >>>> to work as well). >>> >>> Why not ask Christophe if Sympy pypi can use his installers? It seems >>> a shame to send users off-site. >> >> I'd feel more comfortable having people go to his site if they are >> getting his binaries. It's not that I don't trust Christophe Gohlke. >> Obviously he is trustable since a log of people use his installers. >> But if there are ever any issues, we would have to rely on him to fix >> them. I don't like having a single point of failure like that, >> especially when it's not someone within the community. I think it's >> fine to recommend his installers, though. We can remove our own >> builds, and recommend his as an alternative. >> >>> >>>>> >>>>> I'm happy to help with the windows installer. >>>>> >>>>> We have a windows 7 64 bit machine you are also welcome to use; Ondrej >>>>> has login and remote desktop access to that, I can give access to >>>>> anyone who needs it. >>>> >>>> I honestly am still in favor of just not making them any more. I >>>> really like that I can do a whole release of SymPy, including testing, >>>> in under an hour on my machine. Windows installers complicate that >>>> (right now they aren't even tested), and if they will require a >>>> separate machine to make/test, that will complicate things even more. >>> >>> For our own projects, we do nightly runs of building the bdists and >>> installing them and testing them on the buildbots. It would be easy >>> to set that up for Sympy. >>> >>>> We can also look at building wheels. Those are supposed to be the >>>> future on Windows anyway. But there's again the issue of testing. >>>> SymPy is pure Python, so even on Windows a source install shouldn't be >>>> a huge deal, at least relatively speaking. >>> >>>> But if you want to try to implement some stuff, PRs are welcome. >>>> Everything is at https://github.com/sympy/sympy/tree/master/release. >>> >>> Any comment on what you need for the windows installers, other than >>> automated testing? >> >> Well, the real issue here is that it's *really* nice to be able to >> build, test, and upload the entire release on my machine, in an hour. >> Once you've tasted that it's kind of hard to go back to the hard way. >> Maybe it's possible to do that with Wine, or a VM, but it's a lot of >> work, and frankly, I don't see the value, because we can just point >> people to Windows installers that other people have made that *do* >> work, and that they actively support. And the fact that they are >> really only a convenience for SymPy anyway (since it is pure Python) >> exaserbates this. At any rate, I personally don't intend to spend any >> time making Windows installers work. > > That's fine - I don't think you'll need to spend >>> >>>>> >>>>> The question of whether to defer to (Canopy, Anaconda) has come up a >>>>> few times on various lists. It seems to me that has some serious >>>>> risks that we can avoid by making good windows installers. >>>> >>>> What are the serious risks? >> >> OK, well this is the part where I put the disclaimer that I am (as of >> a week ago) a full time Continuum employee. But I remain lead >> developer of SymPy, and I intend to keep the interests of SymPy to be >> those of the SymPy community. > > Yes - of course this is a complicated problem partly because Continuum > has such strong links to many of the projects through internships and > hiring. > >>> I imagine it is in the interest of (Continuum / Enthought) that most >>> people using Scientific Python will be using (Anaconda, Canopy), for >>> various reasons. The interests of (Continuum / Enthought) may or may >>> not coincide with the interests of the open-source community at large, >>> and they may change. Making OSX and Windows users dependent on >>> Anaconda and / or Canopy makes the whole community vulnerable to >>> changes in interest or policy by the companies, and means that we have >>> to depend on the existence of their support machinery. >>> >>> One of the big draws of Python as compared to MATLAB, say, is that >>> Python is free, open source, and supported by the community. Some >>> proportion of users would be less interested in Python if the >>> ActiveState installer was the only installer for Windows, for example. >>> The same applies to the situation where practical use of scientific >>> python depends on using a large company-owned distribution. >>> >>> Understandably, many developers don't themselves use these large >>> packages, and prefer to install from source. This means a >>> disconnection between the developers and the users. For example, I >>> know that the IPython team advocates one of Canopy or Anaconda for >>> user installs, but I don't think any of the developers in Berkeley use >>> either of these. >>> >>> If we the packagers don't produce binary installers, it takes users >>> and developers away from those supporting these installers, and python >>> distutils problem. That's a damn shame because this is a serious >>> long-term problem in the Python ecosystem. >> >> It's important I think to separate Anaconda (the Continuum Python >> distribution) and conda (its package manager). Conda is open source, >> and can be used independently of Anaconda. Conda is what aims to solve >> the distutils problem, by making it easy to create binary packages in >> a cross-platform way. > > Yes, I know the distinction, but I think we are talking about Anaconda > not conda. > > 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. > >> 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? > >> 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. > > 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. Aaron Meurer > > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/sympy. > For more options, visit https://groups.google.com/groups/opt_out. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
