On Wed, Dec 10, 2008 at 11:10 PM, John Hunter <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, Dec 10, 2008 at 9:20 PM, Darren Dale <[EMAIL PROTECTED]> 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?
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
