Re: [matplotlib-devel] requesting permission to remove traits and configobj

On Wed, Dec 10, 2008 at 11:10 PM, John Hunter <jd...@gm...> wrote:

>
>
> On Wed, Dec 10, 2008 at 9:20 PM, Darren Dale <dsd...@gm...> wrote:
>
>> There has been a report at the bugtracker complaining that matplotlib is
>> overwriting an existing installation of configobj. I had a look at the code
>> and thought the bug report must be a mistake or windows specific, but I just
>> saw similar behavior on my linux system.
>
>
> Ignoring for a minute the question of whether we can/should flush
> configobj/traits, it sounds like the real problem is that setup.cfg is not
> working like we expect it to.  And that is something that should be fixed if
> is broken.  If mpl is installing configobj or traits even if we are telling
> it not to via setup.cfg, then we have a problem.   This is worth knowing,
> since the last mpl release was broken vis-a-vis the default backend on
> win32, which *could* be explained by a broken setup.cfg.
>

I think I figured this our in my sleep last night. I dont think setup.cfg or
setupext.py is broken. Here is what happened:

I have a new system and I want to build mpl. I run setup.py build, with no
setup.cfg, and setupext.py tells me that I dont have configobj and mpl is
going to provide it. That's not what I want, I would rather install it with
kubuntu's package manager, so I do. Now I run setup.py build again and mpl
tells me that it found the configobj I installed with apt-get. Great, so I
run setup.py install and, wait for it, mpl installs its own configobj,
overwriting the one I just installed, because I forgot to delete my build/
which contained a configobj from the first time I ran setup.py build.

This can probably bite us when building the windows installers too,
hopefully Charlie is deletes his build as part of the standard procedure.


I would like to simply remove configobj and traits from our repository. They
>> are only used by the long-neglected experimental traited config package,
>> which is only of interest to developers who can easily install them as
>> external dependencies. Is it ok to remove them? If so, should it be done on
>> all the branches?
>>
>> How long are we going to continue to maintain the different branches? It
>> was so much easier back when we only had to worry about the trunk...
>>
>
> You can remove them from the trunk.  They should remain on the 0.91 branch
> as is (with any known bugs fixed and merged) since that is the point of the
> branch (stability for those who cannot upgrade -- in principle someone might
> be depending on the traited config, in practice unlikely).  As for the 0.98
> branch, it is slated for destruction so no worries.  I share your visceral
> reaction against branches, but my head is starting to override this bodily
> reaction, as I see the need for them in practice.  If we carefully document
> the best practices and motivations in the developerr's guide, we can use
> them advantageously.
>

At least we have a nice overview of the procedure in the developers guide.
Thanks for that.

I will remove these from the trunk, but I might not get to it until this
afternoon or evening. I have something pressing this morning at work.

>
> We have a lot of people contributing to mpl, and approaching or just after
> release time we need some mechanism for stabilizing the tested feature set
> of the release candidate while allowing other development to proceed, and
> branches are the natural mechanism for that.  That we are starting to use
> them is a reflection of the fact that we have many more active developers
> than we ever had before (12 developers contributed between 98.3 and 98.4, it
> used to be just 3 or 4 at a time).   I wouldn't be advocating branches
> otherwise, because I am an advocate of doing things as simply as possible: "Make
> everything as simple as possible, but not simpler.".
>

Having worked with bzr and launchpad for a few months now, I wonder if we
might consider such an approach in the future. I know there has been some
experimentation with a git repository, is git supported on windows now?