[matplotlib-devel] SciPy John Hunter Excellence in Plotting Contest on matplotlib website ?
Hello, At Scipy, we briefly discussed the possibility of having the nicest plots of the John Hunter Excellence in Plotting Contest on matplotlib's website, with the code available. I personnally would love to be able to see those plots again, and the code used to generate them. It would also be a great way to advertise the use of matplotlib for high standard plotting. I would love to work on this. I was thinking that the easiest would probably to do a dedicated website, where we could easily upload the code, the data and the images in high resolution. It would also allow us to have a more modern looking website, more "commercial" than the matplotlib one. Also, we (matplotlib) do not hold the copyrights but I think scipy or numfocus does. Hence, doing this in the name of scipy (or numfocus) would avoid some legal issues. We could then be able to link to this website. What do you think? (We should also include the organizers of the contest in this discussion, but I don't really know how to contact them.) Cheers, N -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] SciPy John Hunter Excellence in Plotting Contest on matplotlib website ?
(I've Cc'd the scipy organizers list who should probably be able to address your questions). On 07/31/2013 06:09 AM, Nelle Varoquaux wrote: Hello, At Scipy, we briefly discussed the possibility of having the nicest plots of the John Hunter Excellence in Plotting Contest on matplotlib's website, with the code available. I personnally would love to be able to see those plots again, and the code used to generate them. It would also be a great way to advertise the use of matplotlib for high standard plotting. I submitted this to the scipy papers repository, but I'm not sure where that content was posted (or if it has been yet). https://github.com/scipy/scipy2013_talks That contains the output of the Sphinx document I used to generate the results (and also what I shared with the judges prior to the conference). I can send you the Sphinx source offline. When we solicited entries, we asked for permission for the Scipy conference to use them. If we want to use them on the matplotlib website, I think we'd need to seek permission for that (or we can, of course, link to what SciPy posts). It was done this way because I didn't want it to appear to be a matplotlib-based competition (though it did turn out that way). I would love to work on this. I was thinking that the easiest would probably to do a dedicated website, where we could easily upload the code, the data and the images in high resolution. It would also allow us to have a more modern looking website, more "commercial" than the matplotlib one. Also, we (matplotlib) do not hold the copyrights but I think scipy or numfocus does. Hence, doing this in the name of scipy (or numfocus) would avoid some legal issues. We could then be able to link to this website. Sure. What I did is not terribly modern looking -- web design is a set of skills I don't really have -- so I'd love it if we could modernize it. What do you think? (We should also include the organizers of the contest in this discussion, but I don't really know how to contact them.) This is a great idea. I think if there's a subdomain (or url) of scipy.org we could use for this to host some static content, that would be ideal. And then we link to it from matplotlib.org. Mike -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] SciPy John Hunter Excellence in Plotting Contest on matplotlib website ?
On 31 July 2013 15:11, Michael Droettboom wrote: > (I've Cc'd the scipy organizers list who should probably be able to > address your questions). > > > On 07/31/2013 06:09 AM, Nelle Varoquaux wrote: > > Hello, > > At Scipy, we briefly discussed the possibility of having the nicest > plots of the John Hunter Excellence in Plotting Contest on matplotlib's > website, with the code available. > I personnally would love to be able to see those plots again, and the code > used to generate them. It would also be a great way to advertise the use of > matplotlib for high standard plotting. > > > I submitted this to the scipy papers repository, but I'm not sure where > that content was posted (or if it has been yet). > > https://github.com/scipy/scipy2013_talks > > That contains the output of the Sphinx document I used to generate the > results (and also what I shared with the judges prior to the conference). > I can send you the Sphinx source offline. > > When we solicited entries, we asked for permission for the Scipy > conference to use them. If we want to use them on the matplotlib website, > I think we'd need to seek permission for that (or we can, of course, link > to what SciPy > posts). It was done this way because I didn't want it to appear to be a > matplotlib-based competition (though it did turn out that way). > The fact that not all submissions are matplotlib is one of the reasons I think this should be done in another website. I've checked out the sources of this github repository. Maybe I can start from there if you send me the sources! > I would love to work on this. I was thinking that the easiest would > probably to do a dedicated website, where we could easily upload the code, > the data and the images in high resolution. It would also allow us to have > a more modern looking website, more "commercial" than the matplotlib one. > > Also, we (matplotlib) do not hold the copyrights but I think scipy or > numfocus does. Hence, doing this in the name of scipy (or numfocus) would > avoid some legal issues. > We could then be able to link to this website. > > > Sure. What I did is not terribly modern looking -- web design is a set of > skills I don't really have -- so I'd love it if we could modernize it. > What do you think? > (We should also include the organizers of the contest in this discussion, > but I don't really know how to contact them.) > > This is a great idea. I think if there's a subdomain (or url) of > scipy.org we could use for this to host some static content, that would > be ideal. And then we link to it from matplotlib.org. > > Mike > > > -- > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] 1.3.0 final tagged and uploaded
I have tagged and uploaded matplotlib 1.3.0 final. Congratulations to all involved! It was a long slog getting this release out, and I appreciate everyone's patience. Once we have binaries uploaded to SourceForge, I will make a formal announcement in the usual channels. Mike -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] SciPy John Hunter Excellence in Plotting Contest on matplotlib website ?
On 07/31/2013 11:38 AM, Andy Ray Terrel wrote: The plan was to have it on the SciPy conference website, but we haven't really got it up. If someone can point me to rendered html, I can ask Jim to put it up there now. The rendered HTML is in the scipy2013_talks github repo. https://github.com/scipy/scipy2013_talks/tree/master/plotting_contest That will be fine for now, and it sounds like Nelle will make the presentation much better down the road, at which case we can update it then. Mike -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.3.0 final tagged and uploaded
In article <[email protected]>, Michael Droettboom wrote: > I have tagged and uploaded matplotlib 1.3.0 final. Congratulations to > all involved! It was a long slog getting this release out, and I > appreciate everyone's patience. > > Once we have binaries uploaded to SourceForge, I will make a formal > announcement in the usual channels. I built the Mac binary on MacOS X 10.6 but have run into two problems: - Most of the unit tests are missing, so I can't properly test the results. But my application that uses matplotlib and TkAgg works fine, so may well be OK. Also, I checked and the installer was trying to build all expected backends (including the native Mac backend). - When the 1.3.0 installer is used to overwrite matplotlib 1.2.1 (and the pytz and dateutil that it installs) it breaks pytz and dateutils, by deleting most of the contents, leaving only a subdir named zoneinfo in each package (with different contents for each package). Installing a new pytz and dateutils and running the 1.3.0 binary installer (overwriting matplotlib 1.3.0 or no matplotlib at all) leaves these packages functional (though it changes the modification date, so it's doing something). I have replicated this several times. I'm not sure whether to upload this installer. It's a bit dangerous and ill tested. -- Russell -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.3.0 final tagged and uploaded
On 7/31/13 8:38 AM, Michael Droettboom wrote: > I have tagged and uploaded matplotlib 1.3.0 final. Congratulations to > all involved! It was a long slog getting this release out, and I > appreciate everyone's patience. > > Once we have binaries uploaded to SourceForge, I will make a formal > announcement in the usual channels. > The main matplotlib.org website's layout seems different. What used to be in the sidebar now seems to be in the middle of the page, and the example images spill into the sidebar. Is this a mistake or is it supposed to be that way? Thanks, Jason -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.3.0 final tagged and uploaded
On 07/31/2013 01:47 PM, Russell E. Owen wrote: > In article <[email protected]>, > Michael Droettboom > wrote: > >> I have tagged and uploaded matplotlib 1.3.0 final. Congratulations to >> all involved! It was a long slog getting this release out, and I >> appreciate everyone's patience. >> >> Once we have binaries uploaded to SourceForge, I will make a formal >> announcement in the usual channels. > I built the Mac binary on MacOS X 10.6 but have run into two problems: > - Most of the unit tests are missing, so I can't properly test the > results. But my application that uses matplotlib and TkAgg works fine, > so may well be OK. Also, I checked and the installer was trying to build > all expected backends (including the native Mac backend). What do you mean the unit tests are missing? They don't run? Can you send the output from nose? Glad to hear about the installer building the macosx backend -- that was pretty serious when it wasn't doing that. > > - When the 1.3.0 installer is used to overwrite matplotlib 1.2.1 (and > the pytz and dateutil that it installs) it breaks pytz and dateutils, by > deleting most of the contents, leaving only a subdir named zoneinfo in > each package (with different contents for each package). > > Installing a new pytz and dateutils and running the 1.3.0 binary > installer (overwriting matplotlib 1.3.0 or no matplotlib at all) leaves > these packages functional (though it changes the modification date, so > it's doing something). I thought you were including pytz and dateutils in your installer. Is that not the case? If not, isn't it enough to document that matplotlib now doesn't ship with these dependencies, and they will need to be installed using pip or other means? Can they be installed afterward and have things work? Cheers, Mike > > I have replicated this several times. > > I'm not sure whether to upload this installer. It's a bit dangerous and > ill tested. > > -- Russell > > > -- > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.3.0 final tagged and uploaded
On 07/31/2013 01:53 PM, Jason Grout wrote: > On 7/31/13 8:38 AM, Michael Droettboom wrote: >> I have tagged and uploaded matplotlib 1.3.0 final. Congratulations to >> all involved! It was a long slog getting this release out, and I >> appreciate everyone's patience. >> >> Once we have binaries uploaded to SourceForge, I will make a formal >> announcement in the usual channels. >> > > The main matplotlib.org website's layout seems different. What used to > be in the sidebar now seems to be in the middle of the page, and the > example images spill into the sidebar. Is this a mistake or is it > supposed to be that way? > The layout has changed, but sidebar has not. Can you provide a screenshot? Note, you can always visit the older version of the website at http://matplotlib.org/1.2.1 for direct comparison. Mike -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.3.0 final tagged and uploaded
In article <[email protected]>, Michael Droettboom wrote: > On 07/31/2013 01:47 PM, Russell E. Owen wrote: > > In article <[email protected]>, > > Michael Droettboom > > wrote: > > > >> I have tagged and uploaded matplotlib 1.3.0 final. Congratulations to > >> all involved! It was a long slog getting this release out, and I > >> appreciate everyone's patience. > >> > >> Once we have binaries uploaded to SourceForge, I will make a formal > >> announcement in the usual channels. > > I built the Mac binary on MacOS X 10.6 but have run into two problems: > > - Most of the unit tests are missing, so I can't properly test the > > results. But my application that uses matplotlib and TkAgg works fine, > > so may well be OK. Also, I checked and the installer was trying to build > > all expected backends (including the native Mac backend). > > What do you mean the unit tests are missing? They don't run? Can you > send the output from nose? I have appended my test log. I don't know how to run the tests using nose, but will be happy to have a go with instructions. (Running "nosetests" in the matplotlib source dir does nothing useful). > Glad to hear about the installer building the macosx backend -- that was > pretty serious when it wasn't doing that. > > > > > - When the 1.3.0 installer is used to overwrite matplotlib 1.2.1 (and > > the pytz and dateutil that it installs) it breaks pytz and dateutils, by > > deleting most of the contents, leaving only a subdir named zoneinfo in > > each package (with different contents for each package). > > > > Installing a new pytz and dateutils and running the 1.3.0 binary > > installer (overwriting matplotlib 1.3.0 or no matplotlib at all) leaves > > these packages functional (though it changes the modification date, so > > it's doing something). > > I thought you were including pytz and dateutils in your installer. Is > that not the case? If not, isn't it enough to document that matplotlib > now doesn't ship with these dependencies, and they will need to be > installed using pip or other means? Can they be installed afterward and > have things work? matplotlib used to include pytz and dateutil in its installation. This seemed to be a very good thing overall, since it made sure the dependencies were satisfied, though it is possible that it occasionally overwrite a version the user would have preferred to have. In any case the matplotlib developers removed support for this feature in 1.3. As a result, binary installers now have to tell users to install these packages manually (as well as six and pyparsing). It may be possible to postprocess the Mac binary installer to install these packages, but I don't know how to do it. The problem is that under some circumstances the new installer may trash existing installations of python-dateutils and pytz. I consider that unacceptable. Why break things that are already installed? In other words, we seem to have the worst of the old world and the new: don't install the new packages but perhaps break them if they already exist. Unfortunately breakage is likely to be the norm because most users will be upgrading from matplotlib 1.2.1. -- Russell --- log of attempts to run tests - Last login: Wed Jul 31 09:33:19 on ttys000 rowen$ python -c "import matplotlib as m ; m.test(verbosity=1)" == ERROR: Failure: AttributeError ('module' object has no attribute 'test_agg') -- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac kages/nose/loader.py", line 402, in loadTestsFromName module = resolve_name(addr.module) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac kages/nose/util.py", line 321, in resolve_name obj = getattr(obj, part) AttributeError: 'module' object has no attribute 'test_agg' == ERROR: Failure: AttributeError ('module' object has no attribute 'test_arrow_patches') -- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac kages/nose/loader.py", line 402, in loadTestsFromName module = resolve_name(addr.module) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac kages/nose/util.py", line 321, in resolve_name obj = getattr(obj, part) AttributeError: 'module' object has no attribute 'test_arrow_patches' == ERROR: Failure: AttributeError ('module' object has no attribute 'test_artist') -- Tracebac
Re: [matplotlib-devel] 1.3.0 final tagged and uploaded
In article <[email protected]>, Michael Droettboom wrote: > On 07/31/2013 01:47 PM, Russell E. Owen wrote: > > In article <[email protected]>, > > Michael Droettboom > > wrote: > > > >> I have tagged and uploaded matplotlib 1.3.0 final. Congratulations to > >> all involved! It was a long slog getting this release out, and I > >> appreciate everyone's patience. > >> > >> Once we have binaries uploaded to SourceForge, I will make a formal > >> announcement in the usual channels. > > I built the Mac binary on MacOS X 10.6 but have run into two problems: > > - Most of the unit tests are missing, so I can't properly test the > > results. But my application that uses matplotlib and TkAgg works fine, > > so may well be OK. Also, I checked and the installer was trying to build > > all expected backends (including the native Mac backend). > > What do you mean the unit tests are missing? They don't run? Can you > send the output from nose? > > Glad to hear about the installer building the macosx backend -- that was > pretty serious when it wasn't doing that. Yes. All the interesting information about a build is printed at the beginning and soon scrolls out of sight, so it's usually not obvious if a build is missing something expected. That seems to be standard for unix and distutils installers, so I suspect it would not be trivial to change. Would it make sense to add a unit test that verifies the mac backend was built? -- Russell -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.3.0 final tagged and uploaded
On 07/31/2013 05:05 PM, Russell E. Owen wrote: > In article <[email protected]>, > Michael Droettboom > wrote: > >> On 07/31/2013 01:47 PM, Russell E. Owen wrote: >>> In article <[email protected]>, >>>Michael Droettboom >>>wrote: >>> I have tagged and uploaded matplotlib 1.3.0 final. Congratulations to all involved! It was a long slog getting this release out, and I appreciate everyone's patience. Once we have binaries uploaded to SourceForge, I will make a formal announcement in the usual channels. >>> I built the Mac binary on MacOS X 10.6 but have run into two problems: >>> - Most of the unit tests are missing, so I can't properly test the >>> results. But my application that uses matplotlib and TkAgg works fine, >>> so may well be OK. Also, I checked and the installer was trying to build >>> all expected backends (including the native Mac backend). >> What do you mean the unit tests are missing? They don't run? Can you >> send the output from nose? > I have appended my test log. I don't know how to run the tests using > nose, but will be happy to have a go with instructions. (Running > "nosetests" in the matplotlib source dir does nothing useful). Thanks. It's using nose under the hood, so that's exactly what I meant. I should have been more clear. I'm not sure what might be causing this. As a sanity check (and maybe you've already done this), have you tried doing "rm -rf matplotlib*" in your site-packages directory? > >> Glad to hear about the installer building the macosx backend -- that was >> pretty serious when it wasn't doing that. >> >>> - When the 1.3.0 installer is used to overwrite matplotlib 1.2.1 (and >>> the pytz and dateutil that it installs) it breaks pytz and dateutils, by >>> deleting most of the contents, leaving only a subdir named zoneinfo in >>> each package (with different contents for each package). >>> >>> Installing a new pytz and dateutils and running the 1.3.0 binary >>> installer (overwriting matplotlib 1.3.0 or no matplotlib at all) leaves >>> these packages functional (though it changes the modification date, so >>> it's doing something). >> I thought you were including pytz and dateutils in your installer. Is >> that not the case? If not, isn't it enough to document that matplotlib >> now doesn't ship with these dependencies, and they will need to be >> installed using pip or other means? Can they be installed afterward and >> have things work? > matplotlib used to include pytz and dateutil in its installation. This > seemed to be a very good thing overall, since it made sure the > dependencies were satisfied, though it is possible that it occasionally > overwrite a version the user would have preferred to have. It also made it impossible to install security updates in those other packages, which was a problem for Linux distros, MacPorts, homebrew, etc. > > In any case the matplotlib developers removed support for this feature > in 1.3. As a result, binary installers now have to tell users to install > these packages manually (as well as six and pyparsing). It may be > possible to postprocess the Mac binary installer to install these > packages, but I don't know how to do it. I thought that was the solution we had arrived at in the earlier discussion. I'm sorry if I misunderstood. If you "python setup.py install" matplotlib into a fresh virtualenv, it will install all of these dependencies. Then that virtualenv's site-packages directory can be used as the basis for the contents of the installer. As I'm not a Mac guy, and I don't understand how the installer is built, is there a reason that wouldn't work? > > The problem is that under some circumstances the new installer may trash > existing installations of python-dateutils and pytz. I consider that > unacceptable. Why break things that are already installed? Have you investigated how that's happening? There are no components by that name in the current matplotlib, so they shouldn't be touched, unless the old matplotlib was using .pth files for them or something, I suppose, but I don't think it was by default. Have you investigated what exactly the installer is clobbering? Maybe take a snapshot of the site-packages tree before the installer and then using a tree diffing tool to see what the differences are afterward. > > In other words, we seem to have the worst of the old world and the new: > don't install the new packages but perhaps break them if they already > exist. Unfortunately breakage is likely to be the norm because most > users will be upgrading from matplotlib 1.2.1. I think we need to get to the bottom of why it's breaking the old installations of pytz and dateutil. Then we can hopefully address that. Does the installer try to uninstall what the old installer installed first, perhaps? Mike > > -- Russell > > --- log of attempts to run tests - > > Last login: Wed Jul 31 09:33:19
Re: [matplotlib-devel] 1.3.0 final tagged and uploaded
On 07/31/2013 05:12 PM, Russell E. Owen wrote: > In article <[email protected]>, > Michael Droettboom > wrote: > >> On 07/31/2013 01:47 PM, Russell E. Owen wrote: >>> In article <[email protected]>, >>>Michael Droettboom >>>wrote: >>> I have tagged and uploaded matplotlib 1.3.0 final. Congratulations to all involved! It was a long slog getting this release out, and I appreciate everyone's patience. Once we have binaries uploaded to SourceForge, I will make a formal announcement in the usual channels. >>> I built the Mac binary on MacOS X 10.6 but have run into two problems: >>> - Most of the unit tests are missing, so I can't properly test the >>> results. But my application that uses matplotlib and TkAgg works fine, >>> so may well be OK. Also, I checked and the installer was trying to build >>> all expected backends (including the native Mac backend). >> What do you mean the unit tests are missing? They don't run? Can you >> send the output from nose? >> >> Glad to hear about the installer building the macosx backend -- that was >> pretty serious when it wasn't doing that. > Yes. > > All the interesting information about a build is printed at the > beginning and soon scrolls out of sight, so it's usually not obvious if > a build is missing something expected. > > That seems to be standard for unix and distutils installers, so I > suspect it would not be trivial to change. Would it make sense to add a > unit test that verifies the mac backend was built? > That's a good idea. And we skip it on other platforms ;) Mike -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.3.0 final tagged and uploaded
In article <[email protected]>, Michael Droettboom wrote: > On 07/31/2013 05:05 PM, Russell E. Owen wrote: > > In article <[email protected]>, > > Michael Droettboom > > wrote: > > > >> On 07/31/2013 01:47 PM, Russell E. Owen wrote: > >>> In article <[email protected]>, > >>>Michael Droettboom > >>>wrote: > >>> > I have tagged and uploaded matplotlib 1.3.0 final. Congratulations to > all involved! It was a long slog getting this release out, and I > appreciate everyone's patience. > > Once we have binaries uploaded to SourceForge, I will make a formal > announcement in the usual channels. > >>> I built the Mac binary on MacOS X 10.6 but have run into two problems: > >>> - Most of the unit tests are missing, so I can't properly test the > >>> results. But my application that uses matplotlib and TkAgg works fine, > >>> so may well be OK. Also, I checked and the installer was trying to build > >>> all expected backends (including the native Mac backend). > >> What do you mean the unit tests are missing? They don't run? Can you > >> send the output from nose? > > I have appended my test log. I don't know how to run the tests using > > nose, but will be happy to have a go with instructions. (Running > > "nosetests" in the matplotlib source dir does nothing useful). > > Thanks. It's using nose under the hood, so that's exactly what I > meant. I should have been more clear. > > I'm not sure what might be causing this. As a sanity check (and maybe > you've already done this), have you tried doing "rm -rf matplotlib*" in > your site-packages directory? > > > > >> Glad to hear about the installer building the macosx backend -- that was > >> pretty serious when it wasn't doing that. > >> > >>> - When the 1.3.0 installer is used to overwrite matplotlib 1.2.1 (and > >>> the pytz and dateutil that it installs) it breaks pytz and dateutils, by > >>> deleting most of the contents, leaving only a subdir named zoneinfo in > >>> each package (with different contents for each package). > >>> > >>> Installing a new pytz and dateutils and running the 1.3.0 binary > >>> installer (overwriting matplotlib 1.3.0 or no matplotlib at all) leaves > >>> these packages functional (though it changes the modification date, so > >>> it's doing something). > >> I thought you were including pytz and dateutils in your installer. Is > >> that not the case? If not, isn't it enough to document that matplotlib > >> now doesn't ship with these dependencies, and they will need to be > >> installed using pip or other means? Can they be installed afterward and > >> have things work? > > matplotlib used to include pytz and dateutil in its installation. This > > seemed to be a very good thing overall, since it made sure the > > dependencies were satisfied, though it is possible that it occasionally > > overwrite a version the user would have preferred to have. > > It also made it impossible to install security updates in those other > packages, which was a problem for Linux distros, MacPorts, homebrew, etc. I confess I'm surprised because this feature was disabled by default. I had to manually enable it whenever I made a binary installer by editing setup.cfg. > > In any case the matplotlib developers removed support for this feature > > in 1.3. As a result, binary installers now have to tell users to install > > these packages manually (as well as six and pyparsing). It may be > > possible to postprocess the Mac binary installer to install these > > packages, but I don't know how to do it. > > I thought that was the solution we had arrived at in the earlier > discussion. I'm sorry if I misunderstood. If you "python setup.py > install" matplotlib into a fresh virtualenv, it will install all of > these dependencies. Then that virtualenv's site-packages directory can > be used as the basis for the contents of the installer. As I'm not a > Mac guy, and I don't understand how the installer is built, is there a > reason that wouldn't work? I build the Mac binaries using bdist_mpkg. I'm afraid I don't know how it works under the hood. It creates an "mpkg" binary installer in the dist subdirectory. To run tests, I install matplotlib (using that mpkg installer), since there isn't an obvious way to tests on the mpkg. I'm sure it's possible to accumulate all the files as you suggest and turn them into a binary installer, but I don't know how to do it. Is it useful in the long term to have such a packager? My impression is that as soon as packaging is more robust we'll switch to using pip or easy_install. > > The problem is that under some circumstances the new installer may trash > > existing installations of python-dateutils and pytz. I consider that > > unacceptable. Why break things that are already installed? > > Have you investigated how that's happening? There are no components by > that name in the current matplotlib, so they shouldn't
Re: [matplotlib-devel] 1.3.0 final tagged and uploaded
On 2013/07/31 11:12 AM, Russell E. Owen wrote: > All the interesting information about a build is printed at the > beginning and soon scrolls out of sight, so it's usually not obvious if > a build is missing something expected. I think we could collect that information and re-print it to the screen at the end. Eric -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.3.0 final tagged and uploaded
On 7/31/13 11:02 AM, Michael Droettboom wrote: > The layout has changed, but sidebar has not. Can you provide a > screenshot? Note, you can always visit the older version of the website > at http://matplotlib.org/1.2.1 for direct comparison. I just realized I had the webpage zoomed in (apple/control +), which was part of the problem. It looks great when I unzoom the page. Sorry for the false alarm. I'm really excited about the webagg backend. Thanks for all your work on this release! Jason -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.3.0 final tagged and uploaded
On 2013/07/31 8:02 AM, Michael Droettboom wrote: > The layout has changed, but sidebar has not. Can you provide a > screenshot? Note, you can always visit the older version of the website > athttp://matplotlib.org/1.2.1 for direct comparison. The problem is that the new layout only works with a wider window than was required for the old layout. I think this is a step backward. Eric -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.3.0 final tagged and uploaded
On 7/31/13 2:05 PM, Russell E. Owen wrote: > As a result, binary installers now have to tell users to install > these packages manually (as well as six and pyparsing). I don't think six is mentioned in the "What's new" note for 1.3.0. It just details that pyparsing, pytz, and dateutil are now dependencies. Can you add six to the notes as well, if it is also moving to "dependency" status? Thanks, Jason -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.3.0 final tagged and uploaded
On 07/31/2013 10:18 PM, Jason Grout wrote: > On 7/31/13 2:05 PM, Russell E. Owen wrote: >> As a result, binary installers now have to tell users to install >> these packages manually (as well as six and pyparsing). > I don't think six is mentioned in the "What's new" note for 1.3.0. It > just details that pyparsing, pytz, and dateutil are now dependencies. > Can you add six to the notes as well, if it is also moving to > "dependency" status? > six is a dependency of dateutil. I don't know if we should be in the business of listing all secondary dependencies -- when would we stop? Mike -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.3.0 final tagged and uploaded
On 7/31/13 8:17 PM, Michael Droettboom wrote: > On 07/31/2013 10:18 PM, Jason Grout wrote: >> On 7/31/13 2:05 PM, Russell E. Owen wrote: >>> As a result, binary installers now have to tell users to install >>> these packages manually (as well as six and pyparsing). >> I don't think six is mentioned in the "What's new" note for 1.3.0. It >> just details that pyparsing, pytz, and dateutil are now dependencies. >> Can you add six to the notes as well, if it is also moving to >> "dependency" status? >> > six is a dependency of dateutil. I don't know if we should be in the > business of listing all secondary dependencies -- when would we stop? > Given that six was distributed with matplotlib and is no longer being distributed (right?), I think it makes sense to list it. I would stop at the software that never was part of matplotlib. Thanks, Jason -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
