Building documentation and matplotlibrc

Development matplotlib-devel
41

Ah, all the more reason to apply abspath() or realpath(). To decide which to use, let’s consider the case of someone (like a developer) having multiple builds of matplotlib in separate directories, and uses a symlink to point to whichever he wants to use at the moment.

The question is, in this use-case, would we want the symbolic link pathname, or the absolute pathname? I don’t mess around with docs enough to know which I would want.

I have attached a modified patch (which uses realpath(), but could easily be changed to abspath()). I also included some comments to more fully document what is going on and the rational for the logic being taken.

Ben Root

P.S. - Just to make sure, I noticed that rcParamsOrig is only in the maintenance branch. It was intended to leave the development branch “broken” for now until we get this working properly?

exampledirpath.patch (1.16 KB)

···

On Thu, Jan 6, 2011 at 12:32 PM, John Hunter <jdh2358@…552…149…> wrote:

On Thu, Jan 6, 2011 at 12:22 PM, John Hunter <jdh2358@…149…> wrote:

matplotlib_fname() always returns absolute path. I have not used

realpath, but if you think there is a use for it here, feel free to

post an amended patch.

There is an exception to this – if MATPLOTLIBRC or MPLCONFIGDIR are

relative paths, then matplotlib_fname will return a relative path too.

42

Ah, all the more reason to apply abspath() or realpath(). To decide which
to use, let's consider the case of someone (like a developer) having
multiple builds of matplotlib in separate directories, and uses a symlink to
point to whichever he wants to use at the moment.

The question is, in this use-case, would we want the symbolic link pathname,
or the absolute pathname? I don't mess around with docs enough to know
which I would want.

I have attached a modified patch (which uses realpath(), but could easily be
changed to abspath()). I also included some comments to more fully document
what is going on and the rational for the logic being taken.

OK, I incorporated your changes and committed. Thanks.

P.S. - Just to make sure, I noticed that rcParamsOrig is only in the
maintenance branch. It was intended to leave the development branch
"broken" for now until we get this working properly?

That's correct, but I just did a big merge of all the branch changes
so the trunk is fixed as well now.

JDH

···

On Thu, Jan 6, 2011 at 1:24 PM, Benjamin Root <ben.root@...553...> wrote:

43

Hi John,

Ah, all the more reason to apply abspath() or realpath(). To decide which
to use, let's consider the case of someone (like a developer) having
multiple builds of matplotlib in separate directories, and uses a symlink to
point to whichever he wants to use at the moment.

The question is, in this use-case, would we want the symbolic link pathname,
or the absolute pathname? I don't mess around with docs enough to know
which I would want.

I have attached a modified patch (which uses realpath(), but could easily be
changed to abspath()). I also included some comments to more fully document
what is going on and the rational for the logic being taken.

OK, I incorporated your changes and committed. Thanks.

Just to be sure: this patch is *not* in the released 1.0.1 tarball
(and it will be included in the next released version), is that
correct?

Anyhow, with a bit of hackery in our building process, I'm able to
prepare Debian packages without download anything from the net: thanks
a lot for your support throughout all the process!!

Cheers,

···

On Thu, Jan 6, 2011 at 20:57, John Hunter <jdh2358@...149...> wrote:

On Thu, Jan 6, 2011 at 1:24 PM, Benjamin Root <ben.root@...553...> wrote:

--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

44

John,

Just to clarify, have we officially released 1.0.1, or are we still in the RC phase? If we haven’t released yet, what is the deadline for final patches for 1.0.1?

Ben Root

45

1.0.1 is final but I held off on the announcement until Russel got the
OSX builds uploaded (which he did yesterday, but I still haven't
gotten to the announcement). If there are significant problems (eg
the 3D stuff you reported or other issues) I have no problem pushing
out 1.0.2 quickly.

JDH

···

On Mon, Jan 10, 2011 at 6:45 PM, Benjamin Root <ben.root@...553...> wrote:

John,

Just to clarify, have we officially released 1.0.1, or are we still in the
RC phase? If we haven't released yet, what is the deadline for final
patches for 1.0.1?

46

John,

I am fine with letting 1.0.1 go out as is (unless we can’t live with the documentation typos that has shown up). I am also hesistant about putting out yet another bug-fix release because there will be distros that will have 1.0.0, 1.0.1, and then possibly others with 1.0.2, which would turn into a maintenance nightmare. Instead, let’s just let those package maintainers keep up with the patches to 1.0.1.

This also raises a question. When putting out maintenance patches, are we going to have to patch 1.0.0 and 1.0.1?

I think what happened with 1.0.1 is that while there were some clear goals (solidification of the backend codes and getting the no-download doc feature working), it also became a bit of a free-for-all for receiving other patches (I am guilty of this). Personally, I lost sight
of the point of the RCs and that is to seek out and squash only the show-stopper bugs. Any other patches should not go in.

Looking forward, I think there are a couple of things that we can do for the next release (1.1.0?) that would be greatly beneficial. First, I think having a clear and firm (but not set-in-stone) release date is important. Second, release candidates should probably be made available for a couple of weeks. Third, I think when it comes time for a release, there should be at least one or two other developers agreeing on the release (the purpose of this is to give a last-chance for any objections, and to share the responsibility of the release). Last, there should probably be clearer goals/milestones for the releases.

I would appreciate any thoughts/comments on this. We can start up a new thread if it is more appropriate.

Ben Root

···

On Tue, Jan 11, 2011 at 3:13 PM, John Hunter <jdh2358@…149…> wrote:

On Mon, Jan 10, 2011 at 6:45 PM, Benjamin Root <ben.root@…553…> wrote:

John,

Just to clarify, have we officially released 1.0.1, or are we still in the

RC phase? If we haven’t released yet, what is the deadline for final

patches for 1.0.1?

1.0.1 is final but I held off on the announcement until Russel got the

OSX builds uploaded (which he did yesterday, but I still haven’t

gotten to the announcement). If there are significant problems (eg

the 3D stuff you reported or other issues) I have no problem pushing

out 1.0.2 quickly.

JDH

47

Ben,

It sounds like what you are talking about is more like the way numpy has been working, complete with a release manager. Would you be willing and able to take on that role, along with all the other excellent work you have been doing? It would be a big step forward for mpl, I think.

Eric

···

On 01/12/2011 07:20 AM, Benjamin Root wrote:

On Tue, Jan 11, 2011 at 3:13 PM, John Hunter <jdh2358@...149... > <mailto:jdh2358@…149…>> wrote:

    On Mon, Jan 10, 2011 at 6:45 PM, Benjamin Root <ben.root@...553... > <mailto:ben.root@…553…>> wrote:
     > John,
     >
     > Just to clarify, have we officially released 1.0.1, or are we
    still in the
     > RC phase? If we haven't released yet, what is the deadline for final
     > patches for 1.0.1?
     >

    1.0.1 is final but I held off on the announcement until Russel got the
    OSX builds uploaded (which he did yesterday, but I still haven't
    gotten to the announcement). If there are significant problems (eg
    the 3D stuff you reported or other issues) I have no problem pushing
    out 1.0.2 quickly.

    JDH

John,

I am fine with letting 1.0.1 go out as is (unless we can't live with the
documentation typos that has shown up). I am also hesistant about
putting out yet another bug-fix release because there will be distros
that will have 1.0.0, 1.0.1, and then possibly others with 1.0.2, which
would turn into a maintenance nightmare. Instead, let's just let those
package maintainers keep up with the patches to 1.0.1.

This also raises a question. When putting out maintenance patches, are
we going to have to patch 1.0.0 and 1.0.1?

I think what happened with 1.0.1 is that while there were some clear
goals (solidification of the backend codes and getting the no-download
doc feature working), it also became a bit of a free-for-all for
receiving other patches (I am guilty of this). Personally, I lost sight
of the point of the RCs and that is to seek out and squash only the
show-stopper bugs. Any other patches should not go in.

Looking forward, I think there are a couple of things that we can do for
the next release (1.1.0?) that would be greatly beneficial. First, I
think having a clear and firm (but not set-in-stone) release date is
important. Second, release candidates should probably be made available
for a couple of weeks. Third, I think when it comes time for a release,
there should be at least one or two other developers agreeing on the
release (the purpose of this is to give a last-chance for any
objections, and to share the responsibility of the release). Last,
there should probably be clearer goals/milestones for the releases.

I would appreciate any thoughts/comments on this. We can start up a new
thread if it is more appropriate.

Ben Root

48

I am fine with letting 1.0.1 go out as is (unless we can't live with the

is already out: look at SF download page to see how many have downloaded it.

documentation typos that has shown up). I am also hesistant about putting
out yet another bug-fix release because there will be distros that will have
1.0.0, 1.0.1, and then possibly others with 1.0.2, which would turn into a
maintenance nightmare. Instead, let's just let those package maintainers
keep up with the patches to 1.0.1.

This also raises a question. When putting out maintenance patches, are we
going to have to patch 1.0.0 and 1.0.1?

If you're saying you want to publish another tarball with version
1.0.1 that has different contents of the current one, than with my
distro package maintainer and programmer hats on I say "you should
not". If you have published (and not advertised, ok) something, you
cannot re-publish the same version but with something "different" in
it. Just go with 1.0.2, distros have (usually) the latest version and
you are free to release patches in the HEAD of your development tree:
it's a distro package maintainer evaluate if this patches are to be
backported to the distro version, if the version cannot be bring
up-to-date with the latest release.

Cheers,

···

On Wed, Jan 12, 2011 at 18:20, Benjamin Root <ben.root@...553...> wrote:
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

49

Exactly, once we upload a version with a number, it is fixed. It
becomes really difficult to debug when two people think they are using
the same code and looking at different bases.

···

On Wed, Jan 12, 2011 at 1:09 PM, Sandro Tosi <morph@...12...> wrote:

If you're saying you want to publish another tarball with version
1.0.1 that has different contents of the current one, than with my
distro package maintainer and programmer hats on I say "you should
not". If you have published (and not advertised, ok) something, you
cannot re-publish the same version but with something "different" in
it. Just go with 1.0.2, distros have (usually) the latest version and
you are free to release patches in the HEAD of your development tree:
it's a distro package maintainer evaluate if this patches are to be
backported to the distro version, if the version cannot be bring
up-to-date with the latest release.

50

I am fine with letting 1.0.1 go out as is (unless we can’t live with the

is already out: look at SF download page to see how many have downloaded it.

documentation typos that has shown up). I am also hesistant about putting

out yet another bug-fix release because there will be distros that will have

1.0.0, 1.0.1, and then possibly others with 1.0.2, which would turn into a

maintenance nightmare. Instead, let’s just let those package maintainers

keep up with the patches to 1.0.1.

This also raises a question. When putting out maintenance patches, are we

going to have to patch 1.0.0 and 1.0.1?

If you’re saying you want to publish another tarball with version

1.0.1 that has different contents of the current one, than with my

distro package maintainer and programmer hats on I say "you should

not". If you have published (and not advertised, ok) something, you

cannot re-publish the same version but with something “different” in

it. Just go with 1.0.2, distros have (usually) the latest version and

you are free to release patches in the HEAD of your development tree:

it’s a distro package maintainer evaluate if this patches are to be

backported to the distro version, if the version cannot be bring

up-to-date with the latest release.

Cheers,

I believe we are actually in agreement, but perhaps I wasn’t clear enough. The maintenance patches that I speak of are committed in the v1_0_maint branch of the svn repo. The tarball still has the original code from the release point regardless of what patches have been committed since then.

Package maintainers can choose to cherry-pick those patches or even track that maintenance branch for their own packaging purposes. The point is that new features should not be added (unless absolutely necessary) and that old features are not removed on that branch.

Please see our coding guide under “Committing Changes” (particularly the last bullet):

Keep the maintenance branch (0.91) the latest release branch (eg
0.98.4) and trunk in sync where it makes sense. If there is a bug
on both that needs fixing, use svnmerge.py to keep them in
sync.

So, back to the issue regarding whether to put out a 1.0.2 or not. We will always be wanting to patch things (lord knows there are enough bugs…) and at some point we have to say “it is good enough”. Right now, my only major qualm with the current 1.0.1 release has been the documentation (by the way, the Coding Guide page looks terrible on my small screen). Code-wise, I am willing to accept it as is and start focusing on 1.1.0.

Ben Root

···

On Wed, Jan 12, 2011 at 1:09 PM, Sandro Tosi <morph@…12…> wrote:

On Wed, Jan 12, 2011 at 18:20, Benjamin Root <ben.root@…553…> wrote:

51

I agree, I think that is the direction MPL needs to go. We are feature-packed, but still have a lot of rough edges. The prospect of being a release manager is great, but it will depend on when we plan to release if I will have enough time to devote to that.

Ben Root

···

On Wed, Jan 12, 2011 at 12:56 PM, Eric Firing <efiring@…229…> wrote:

On 01/12/2011 07:20 AM, Benjamin Root wrote:

On Tue, Jan 11, 2011 at 3:13 PM, John Hunter <jdh2358@…149… > > mailto:jdh2358@...149...> wrote:

On Mon, Jan 10, 2011 at 6:45 PM, Benjamin Root <ben.root@...553... > >     <mailto:ben.root@...553...>> wrote:

 > John,

 >

 > Just to clarify, have we officially released 1.0.1, or are we

still in the

 > RC phase?  If we haven't released yet, what is the deadline for final

 > patches for 1.0.1?

 >

1.0.1 is final but I held off on the announcement until Russel got the

OSX builds uploaded (which he did yesterday, but I still haven't

gotten to the announcement).  If there are significant problems (eg

the 3D stuff you reported or other issues) I have no problem pushing

out 1.0.2 quickly.

JDH

John,

I am fine with letting 1.0.1 go out as is (unless we can’t live with the

documentation typos that has shown up). I am also hesistant about

putting out yet another bug-fix release because there will be distros

that will have 1.0.0, 1.0.1, and then possibly others with 1.0.2, which

would turn into a maintenance nightmare. Instead, let’s just let those

package maintainers keep up with the patches to 1.0.1.

This also raises a question. When putting out maintenance patches, are

we going to have to patch 1.0.0 and 1.0.1?

I think what happened with 1.0.1 is that while there were some clear

goals (solidification of the backend codes and getting the no-download

doc feature working), it also became a bit of a free-for-all for

receiving other patches (I am guilty of this). Personally, I lost sight

of the point of the RCs and that is to seek out and squash only the

show-stopper bugs. Any other patches should not go in.

Looking forward, I think there are a couple of things that we can do for

the next release (1.1.0?) that would be greatly beneficial. First, I

think having a clear and firm (but not set-in-stone) release date is

important. Second, release candidates should probably be made available

for a couple of weeks. Third, I think when it comes time for a release,

there should be at least one or two other developers agreeing on the

release (the purpose of this is to give a last-chance for any

objections, and to share the responsibility of the release). Last,

there should probably be clearer goals/milestones for the releases.

I would appreciate any thoughts/comments on this. We can start up a new

thread if it is more appropriate.

Ben Root

Ben,

It sounds like what you are talking about is more like the way numpy has

been working, complete with a release manager. Would you be willing and

able to take on that role, along with all the other excellent work you

have been doing? It would be a big step forward for mpl, I think.

Eric