Binary release process

Development matplotlib-devel
1

First of all let me apologize for the problems we have been
seeing with the binaries as of late. Frankly the root of the problem
might be my detachment from the matplotlib source for some time.
Unfortunately due to my time constraints, this won't be changing soon.
I used to think being somewhat on the outside helped me keep the ease
of the build process in check. This gap has apparently grown too
wide.
     Moving ahead, python 2.6 and 3.0 are going to pose new challenges
since they require new versions of visual studio I do not have access
to. Doing builds for 4 windows versions poses a great time to work on
a standard cygwin build setup (not that the cygwin build process
doesn't work as is). In addition to that we are going to possibly be
seeing osx fat binaries with 4 architectures! I am more than happy to
continue to contribute my time to create these builds, but I think it
only makes sense to have a release candidate cycle before formally
pushing to sourceforge.

- Charlie

2

First of all let me apologize for the problems we have been

seeing with the binaries as of late. Frankly the root of the problem

might be my detachment from the matplotlib source for some time.

Unfortunately due to my time constraints, this won’t be changing soon.

I used to think being somewhat on the outside helped me keep the ease

of the build process in check. This gap has apparently grown too

wide.

I appreciate that this is a difficult task and that you have plenty of other responsibilities, and appreciate your effort. However, I’ve been trying to get to the bottom of why the windows installer is overwriting configobj and I could use some feedback from you. I really need to know whether you delete the build/ directory before creating a new installer.

 Moving ahead, python 2.6 and 3.0 are going to pose new challenges

since they require new versions of visual studio I do not have access

to.

I think 2.6 and 3.0 were both compiled with Visual C++ 2008, and so the free Visual C++ 2008 express can be used to create extension modules. I the past I have built and distributed extension modules built with mingw32 on windows XP, but I have not been able to put together a working mingw32/msys on a 64-bit windows vista machine. This is my only windows computer, so it looks like I will only be supporting py2.6 in the near future.

Doing builds for 4 windows versions poses a great time to work on

a standard cygwin build setup (not that the cygwin build process

doesn’t work as is). In addition to that we are going to possibly be

seeing osx fat binaries with 4 architectures! I am more than happy to

continue to contribute my time to create these builds, but I think it

only makes sense to have a release candidate cycle before formally

pushing to sourceforge.

What are the four architectures? I’d be willing to get things together on my windows install so I can build mpl from source and help test with python-2.6. (I know I’m going to regret this.)

Darren

···

On Sun, Dec 14, 2008 at 12:24 PM, Charlie Moad <cwmoad@…149…> wrote:

3

    First of all let me apologize for the problems we have been
seeing with the binaries as of late. Frankly the root of the problem
might be my detachment from the matplotlib source for some time.
Unfortunately due to my time constraints, this won't be changing soon.
I used to think being somewhat on the outside helped me keep the ease
of the build process in check. This gap has apparently grown too
wide.

I appreciate that this is a difficult task and that you have plenty of other
responsibilities, and appreciate your effort. However, I've been trying to
get to the bottom of why the windows installer is overwriting configobj and
I could use some feedback from you. I really need to know whether you delete
the build/ directory before creating a new installer.

I don't have my build directories anymore, but they were made from
extracting the source release so there was no previous build
directory. It is possible that I missed those settings in setup.cfg,
because I do not have either of those module installed.

    Moving ahead, python 2.6 and 3.0 are going to pose new challenges
since they require new versions of visual studio I do not have access
to.

I think 2.6 and 3.0 were both compiled with Visual C++ 2008, and so the free
Visual C++ 2008 express can be used to create extension modules. I the past
I have built and distributed extension modules built with mingw32 on windows
XP, but I have not been able to put together a working mingw32/msys on a
64-bit windows vista machine. This is my only windows computer, so it looks
like I will only be supporting py2.6 in the near future.

Good to know there is a free option.

Doing builds for 4 windows versions poses a great time to work on
a standard cygwin build setup (not that the cygwin build process
doesn't work as is). In addition to that we are going to possibly be
seeing osx fat binaries with 4 architectures! I am more than happy to
continue to contribute my time to create these builds, but I think it
only makes sense to have a release candidate cycle before formally
pushing to sourceforge.

What are the four architectures? I'd be willing to get things together on my
windows install so I can build mpl from source and help test with
python-2.6. (I know I'm going to regret this.)

"32-bit PowerPC, 32-bit x86, 64-bit PowerPC, and 64-bit x86"

···

On Sun, Dec 14, 2008 at 1:22 PM, Darren Dale <dsdale24@...149...> wrote:

On Sun, Dec 14, 2008 at 12:24 PM, Charlie Moad <cwmoad@...149...> wrote:

4

If you did not explicitly disable these modules in setup.cfg, then I think we understand the problem. Would you please make a note that configobj and traits should be explicitly disabled in setup.cfg for future releases of the maintenance branches? It will not be an issue for the trunk.

Thanks,
Darren

···

On Sun, Dec 14, 2008 at 1:58 PM, Charlie Moad <cwmoad@…149…> wrote:

On Sun, Dec 14, 2008 at 1:22 PM, Darren Dale <dsdale24@…149…> wrote:

On Sun, Dec 14, 2008 at 12:24 PM, Charlie Moad <cwmoad@…149…> wrote:

First of all let me apologize for the problems we have been

seeing with the binaries as of late. Frankly the root of the problem

might be my detachment from the matplotlib source for some time.

Unfortunately due to my time constraints, this won’t be changing soon.

I used to think being somewhat on the outside helped me keep the ease

of the build process in check. This gap has apparently grown too

wide.

I appreciate that this is a difficult task and that you have plenty of other

responsibilities, and appreciate your effort. However, I’ve been trying to

get to the bottom of why the windows installer is overwriting configobj and

I could use some feedback from you. I really need to know whether you delete

the build/ directory before creating a new installer.

I don’t have my build directories anymore, but they were made from

extracting the source release so there was no previous build

directory. It is possible that I missed those settings in setup.cfg,

because I do not have either of those module installed.

5

I think this is a good suggestion which we will adopt going forward.
I rushed the process because I was interested in getting a release out
before my talk last week since I wanted to show off some of the new
stuff, and thought we had done this enough times that it would go
smoothly under an expedited schedule, but clearly it did not. So
going forward we will make the release branch first, post release
candidates with binaries, announce testing of them, give them at least
a week to shake out the bugs, fix the changes on the branch and merge
into trunk, and then build the final release from the branch.

I have updated the release_guide instructions in the developer's guide

  matplotlib download | SourceForge.net

What are the architectures you are referring to when you write "osx
fat binaries with 4 architectures". I am not sure what they are, but
I doubt we will choose to support all of them :slight_smile:

I do think having platform specific make scripts which do everything
necessary to checkout and build the dependencies and releases is the
right way to go. As you probably saw from my post yesterday, I wrote
one of these for OSX yesterday and put it in release/osx, so we should
update and use that going forward -- we can refine this even further
to incorporate some testing, etc, but it is a good start. If you have
time to work on an analog for win32, that would be great, otherwise I
may hold my nose and give it a try.

Sorry for the extra workload and stress created by this fumble of a release....

JDH

···

On Sun, Dec 14, 2008 at 11:24 AM, Charlie Moad <cwmoad@...149...> wrote:

    First of all let me apologize for the problems we have been
...snip...
seeing with the binaries as of late. Frankly the root of the problem
seeing osx fat binaries with 4 architectures! I am more than happy to
continue to contribute my time to create these builds, but I think it
only makes sense to have a release candidate cycle before formally
pushing to sourceforge.