When will you have matplotlib 1.5.0?

[le...@neilson-levin.org]

I tried to install using pip (within the conda environment) but this leads to a conflict between the system Tk and the conda Tk because publicly maintained matplotlib doesn't know anything about a conda supplied tk.

Please don't point out, as Travis has, that the matplotlib maintainers can post a build to Anaconda.org. The matplotlib maintainers have posted to Pypi and to their matplotlib repository on github.

You can go snag from either place and re-release.

This is a severe problem with Continuum in general.

[Carlos Córdoba]

Hi,

We were busy with the release of Anaconda 2.4. I think Matplotlib 1.5 will be available this week or at most next one.


Thanks for your patience,
Carlos

El 02/11/15 a las 14:57, le...@neilson-levin.org escribió:

--
Anaconda Community Support Group Brought to you by Continuum Analytics
---
You received this message because you are subscribed to the Google Groups "Anaconda - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to anaconda+u...@continuum.io.
To post to this group, send email to anac...@continuum.io.
Visit this group at http://groups.google.com/a/continuum.io/group/anaconda/.

[Michael Sarahan]

> Please don't point out, as Travis has, that the matplotlib maintainers can post a build to Anaconda.org. The matplotlib maintainers have posted to Pypi and to their matplotlib repository on github.

I agree that this may not be the best option.  Posts to anaconda.org are not necessarily done using the same build tools as the "official" anaconda packages, and there may be library conflicts.  Many package maintainers work directly with us to ensure that we are updating the "official" conda packages for their software.  In fact, Michael Droetboom has contributed a Matplotlib 1.5 recipe to us, but we have been too busy with the simultaneous Anaconda 2.4 release to make that package available.  We have limited resources.  Sorry.

> You can go snag from either place and re-release.

We have historically done this, and IMHO, this is bad for the whole ecosystem.  We have made great efforts in this release to build from source, rather than simply pull binaries that other people have created.  If people package DLLs in their wheels, then this can lead to some major headaches, crashes, and general disfunction when those DLLs are differently versioned from other DLLs that might get picked up.  By compiling from source, we are able to ensure that we keep only one copy of underlying libraries, and moreover, that all packages in our system use the same underlying library.

A unified build system for the Python ecosystem with completely standardized versions of all libraries involved would be awesome, but it's not present as far as I know.  Conda includes TclTk 8.5 because that seemed to be what Matplotlib wanted when I compiled it from source.  Really - there's nothing sinister or proprietary here, just people working hard to make things work in a very complex system.  Python from Python.org includes Tcl/Tk (seemingly version 8.6), but I could not get Matplotlib to recognize that as an adequate installation to build against.  I think it was missing headers.  Tcl/Tk is a very strange package to build, to begin with (please try it sometime - it's a fun Friday night.  Make sure to bring your alcoholic beverage of choice.)

Generally, maintainers appreciate having more people building their software, because it lowers the "bus factor," and because we contribute patches back to the ecosystem.  I fixed Python 3.5 builds for at least 4 packages during this release, and contributed that code upstream in all cases.

> This is a severe problem with Continuum in general.

I would argue that this is a severe problem with software in general.  We (open source projects, Continuum, other package maintainers) are all doing the best we can to make life easier for people.  Finding better ways for all of us to standardize more and work together would be nice, but I would stop short of having only one person building software, and everyone else just using binaries.  Sorry you have hit roadblocks in the complexity of this matter.

Michael

[le...@neilson-levin.org]

You point out some of the significant practical difficulties here.  As you point out part of the problem is the nature of software and particularly, with deep dependency stacks that are difficult for the typical Python user to build "at home."  It seems also quite hard for professional developers "at work."

Lots of  building probably does serve a valid debugging/testing function.  I certainly see that widely used packages, even when built "at home" are more likely to complete successfully, issue fewer compiler warnings and often have many build gotcha's already documented.  Even with that real benefit, it seems a disadvantage to have fragmented repositories, different package management tools, and incompatible package formats (source and binary).  The most challenging case would be the Linux split into .rpm, .deb, and others with their different tools and the repositories being at different ages and even factoring packages differently.  Everyone in that world was trying to make something better, but one wonders if the collective effort could have brought about a better outcome with less duplication of effort.

We have a miniature of this situation in Python and perhaps more possibility of bringing things together.  I realize that conda predates PIP 6+ series with wheels and that it seemed that a solution from PSF was long in the making.  That is certainly not Continuum's fault.  Now perhaps some converged effort is possible?

[Andy Ray Terrel]

On Thu, Nov 5, 2015 at 12:47 PM, <le...@neilson-levin.org> wrote:

You point out some of the significant practical difficulties here.  As you point out part of the problem is the nature of software and particularly, with deep dependency stacks that are difficult for the typical Python user to build "at home."  It seems also quite hard for professional developers "at work."

Lots of  building probably does serve a valid debugging/testing function.  I certainly see that widely used packages, even when built "at home" are more likely to complete successfully, issue fewer compiler warnings and often have many build gotcha's already documented.  Even with that real benefit, it seems a disadvantage to have fragmented repositories, different package management tools, and incompatible package formats (source and binary).  The most challenging case would be the Linux split into .rpm, .deb, and others with their different tools and the repositories being at different ages and even factoring packages differently.  Everyone in that world was trying to make something better, but one wonders if the collective effort could have brought about a better outcome with less duplication of effort.

We have a miniature of this situation in Python and perhaps more possibility of bringing things together.  I realize that conda predates PIP 6+ series with wheels and that it seemed that a solution from PSF was long in the making.  That is certainly not Continuum's fault.  Now perhaps some converged effort is possible?

Python Packaging Authority already recommends conda and has a nice rundown of usages (and the more esoteric Hashdist tool I was a part of but failed to get conda to integrate). https://packaging.python.org/en/latest/current/

-- Andy

[Chris Barker]

On Thu, Nov 5, 2015 at 10:47 AM, <le...@neilson-levin.org> wrote:

We have a miniature of this situation in Python and perhaps more possibility of bringing things together.  I realize that conda predates PIP 6+ series with wheels and that it seemed that a solution from PSF was long in the making.  That is certainly not Continuum's fault.  Now perhaps some converged effort is possible?

Well, not yet -- pip_wheel just can't support the use cases conda was developed to support. And, in fact, if never will -- I don't think pip is ever going to install stuff completely outside of python.

But PyPA is moving in the direction of more flexible dependency specifications, so we may get closer.

-CHB

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris....@noaa.gov

[henrysch...@gmail.com]

1.5.0 seems to be out in Conda! Great job!!!