On 07/31/2013 07:40 PM, Russell E. Owen wrote:
> In article <51f997f0.5060...@stsci.edu>,
> Michael Droettboom <md...@stsci.edu>
> wrote:
>
>> On 07/31/2013 05:05 PM, Russell E. Owen wrote:
>>> In article <51f950cb.7060...@stsci.edu>,
>>> Michael Droettboom <md...@stsci.edu>
>>> wrote:
>>>
>>>> On 07/31/2013 01:47 PM, Russell E. Owen wrote:
>>>>> In article <51f92f58.6020...@stsci.edu>,
>>>>> Michael Droettboom <md...@stsci.edu>
>>>>> 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?
It would be nice to get to the bottom of this puzzle. I'll start
another thread to get the attention of other Mac developers in case
they've seen it before.
>>
>>>> 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.
Ok -- I didn't realize the bdist_mpkg was so tied into a single
distutils package.
One possible way forward: pip has a pybundle option, so you can do:
pip pybundle matplotlib.pybundle matplotlib
which will create a zip file (matplotlib.pybundle) containing a built
matplotlib and all of its dependencies. Then it's just a matter of
making an installer that puts those files in the right place. It
doesn't seem like bdist_mpkg is the right tool for that, but there must
be other tools on the Mac to make installers that juts put files somewhere.
>
> 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.
pip and easy_install already work now -- the problem is that the user
needs to have a compiler and the headers for the C dependencies
(freetype, libpng) installed. "wheels" are a new way to distribute
binaries using pip, and I think that once that's readily available and
robust, it will provide the best of both worlds -- the dependency
resolution *and* the convenience of a binary installer.
>
>>> 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.
> The old matplotlib was not using .pth files (at least I never found any
> in site-packages).
I'm still at a loss as to how the new installer, which includes nothing
to do with python-dateutils and pytz other than importing them, could
trash existing installations of those packages. I think the only way to
find out is to compare the trees before and after to see what it's doing.
>
>>> 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?
> That is an interesting suggestion. I"m not an expert, but I thought mpkg
> files usually didn't know how to uninstall old files (though one can add
> scripts to do this).
>
>
I just wanted to ensure it's not doing anything magical that would cause
the breakage, which it sounds like it's not.
Sorry this has been such a difficult transition -- I think we're getting
there, slowly but surely, though.
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
