I have built it all on Mac. It really was quite terrible--put it all in a bash script and its worse yet on Windows--I tried and quickly went to WinPython or PythonXY in preference to Anaconda or ActiveState, both of which I also tried. I am glad that I don't have to any more. Haven't had to for about a year and a half. Which is why we do want a decent approach to binary distribution. I agree that forking as a way to test innovation with an intention to eventually re-integrate is a fine way to make progress. A permanent fork, on the other hand, seems undesirable though it happens for a variety of reasons.
It appears that Python has stepped up to this, if belatedly and incompletely. There are pre-built binaries available for Mac and Windows for numpy, matplotlib, scipy, and pandas provided by the maintainers of those packages. These folks have stepped up and contributed a lot. There are wheels for Mac and Windows for all of them--except Numpy on Windows. In general, according to the scipy umbrella website, these binaries are targeted to the PSF binary distributions (2.7.10 and 3.5.0--with earlier versions available in many cases). I am afraid that Linux is more challenging though in some cases the package repos for the major distros offer binaries though those are likely to lag. I think the recent breakage in some Python packages has occurred in the cycle of upgrading to work with Python 2.7.10 and 3.5.0. Despite improvement it remains messy. If Julia weren't so very good at integrating other things--Python, C, R, and using git as a package manager--we wouldn't be having the discussion. We are having it because Julia's core team carefully invested where it should--in the defining innovations of the language--while finding very efficient ways to bootstrap some of the maintenance "machinery" and leveraging other platforms for needed capabilities. The pace of progress, as a result, is simply astonishing for a language--really a nascent ecosystem--that has been here such a short time. There are still issues managing large binary dependencies, but it must be done because having thousands of people build very large libraries doesn't make sense. I think Julia user-developers want to use the capabilities Julia provides without becoming sys admins. Sounds like the Julia core team has some ideas for this, especially for statically compiled pure Julia packages (bring'em on!). As to preferences for Python distributions, it seems a few things occasionally break when using PSF Python distro with pip managed packages. It used to work; it will get sorted out. Relying exclusively on a quasi-proprietary distro for the long-term doesn't seem like a good thing, though it has been expedient as an option and it is fine to have more than one option. It makes sense for Julia to provide a self-contained Python for Julia users, especially for matplotlib/PyPlot.jl but also because it is so easy to use PyCall for lots of things. I stirred up a rat's nest here and I am dropping it. In a way, this is more of an issue for the Python community than the Julia community. Julia has adopted a new approach with more up to date and broadly adopted tooling (git--though the binary issue remains) which allows for much more rapid progress. On Monday, November 2, 2015 at 8:52:39 PM UTC-8, Isaiah wrote: > > This is a bit of an attitude issue that got me "off". The matplotlib >> maintainers have no such obligation. > > > Neither does Anaconda. Please stop, this whole discussion is ridiculous, > especially the "forking" nonsense. Conda will update their Matplotlib > version in good time. Dealing with large dependency graphs of binary > dependencies is a thankless pain in the ass [1]. > > Keep in mind that they are giving all of this away *for free*. > > [1] (seriously, unless you've actually built Python and the whole SciPy > binary dependency stack from scratch on Windows, you have absolutely no > business writing philosophical rants about any of this) > > On Mon, Nov 2, 2015 at 11:24 PM, <le...@neilson-levin.org <javascript:>> > wrote: > >> Thanks for the follow-up. Again, I understand the convenience benefit of >> the self-contained conda.jl Python. My concern is about where it leads >> practically. Sorry to bring up the ideology stuff. YMMV. >> >> As a practical matter, if Continuum were much faster to post updates to >> their repo at Anaconda.com this might be less of a problem. On the conda >> group, someone requested a more upgraded matplotlib (this was from some >> time ago and the requester wanted 1.4) and the Continuum reply was that the >> matplotlib maintainers were free to also post their latest to what was then >> called Binstar.com. This is a bit of an attitude issue that got me "off". >> The matplotlib maintainers have no such obligation. They have a master >> branch on their github repo and they release to PyPi. If Continuum wants >> to create their own binary as a service, of course they may--but it's on >> them to do so. >> >> There is now a bug in 1.4.3 with Numpy 1.10 that results in this message: >> >> FutureWarning: elementwise comparison failed; returning scalar instead, >> but in the future will perform elementwise comparison >> >> This was fixed by matplotlib 1.5.0 about 2 weeks ago (along with other >> things of course). Not that long ago and a little bit of a lag as mutual >> dependencies get their issues sorted out isn't unreasonable. But, they >> have and the master branch is fully released. >> >> This is hard for Julia and I was too harsh. With large dependencies >> there is no totally easy way out. Until a week ago I was happily using >> versions of Python I downloaded myself. PyCall was finding them and all >> was good. I ran into one annoying bug after upgrading matplotlib (first >> chart figure cannot be closed by code) so I was trying to sort that out. >> Never figured out what broke. So, I switched to the conda.jl approach and >> moved on. And then there was the latest... ...which lead to my post. >> > >
