Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MEP 12: Gallery cleanup and reorganization #1623

Closed
wants to merge 35 commits into from

Conversation

tonysyu
Copy link
Contributor

@tonysyu tonysyu commented Dec 27, 2012

This pull request lays the groundwork for reorganizing the Matplotlib gallery, as described in MEP 12. To that end, this PR creates a new set of (tentatively-named) sections in the gallery. In addition, a few examples are cleaned up and moved to these new sections to demonstrate the clean up guidelines.

Split demo in to two different examples
Rename fill_demo2 to fill_demo_features to clarify purpose
* Rename to imshow_demo
* Add smaller version of lena image saved as a numpy binary so that use doesn't require PIL
Add new sphinx config variable `mpl_example_sections` and use this list in both `gen_gallery.py` and `gen_rst.py`.

exclude_example_sections = ['units']
multiimage = re.compile('(.*?)(_\d\d){1,2}')
custom_titles = {'pylab_examples' : 'pylab examples',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems a little redundant. Perhaps this dictionary could go in the conf.py?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. Fixed in latest commit.

@mdboom
Copy link
Member

mdboom commented Jan 2, 2013

This looks great. I wonder what the best way to get the rest of the mechanical work done is? I'd suggest merging this PR once any kinks or details are worked out, and then dividing up the gallery examples among some volunteers on the mailing list to update to the new conventions and organization.

@NelleV
Copy link
Member

NelleV commented Jan 7, 2013

This is awesome! I think this is going to help users a lot. Thanks for doing this work.

@tonysyu
Copy link
Contributor Author

tonysyu commented Jan 15, 2013

@NelleV Thanks. Good luck on MEP10. (PS. We miss you over at scikit-image:)

@mdboom Thanks for the feedback. I'm not certain what you mean by mechanical work. The mechanical part for me was checking for and renaming references to examples that I moved. Other than that, I didn't find anything too mechanical. Unless you mean the clean up itself. It might be nice to just have a script that automates some of the more common clean ups. That said, I don't remember anything that was very common amongst the examples that I cleaned up.

As for kinks: I still think the section names that I added could be improved. Some of the sections are too coarse, some are too fine. I guess that's unavoidable. It might also be nice to have more succinct section names. (For example, "lines, bars, and markers" probably deserve a better name. Also, do they really go together? I'd say yes, but I'm not completely convinced.)

@NelleV
Copy link
Member

NelleV commented Jan 15, 2013

@tonysyu I don't do vision anymore: . But you've got Andy contributing now

One thing I would love to see, but probably adds a large amount of work, is titles to examples like there is on scikit-image. I think it helps the user (and sometimes the developper itself) understanding why the example is there, and it makes the page easily searchable.

@mdboom
Copy link
Member

mdboom commented Jan 15, 2013

@tonysu: Yes, I meant what you thought. Mainly the work of categorizing the rest of the examples and putting them in to shape that satisfy the new guidelines in MEP 12. It's not terribly mechanical, I guess -- and least not easy to automate. But it's a lot of work, and if there's an easy way to divide the work, that might be the best way to get it done.

As for the category names: they didn't strike me as terribly bad, and anything is an improvement over the current situation where many are grouped only by implementation style. I think perfect might be the enemy of the good on this one, and maybe we proceed with these and further divide the categories later if the need arises.

@mdboom mdboom mentioned this pull request Jan 16, 2013
@tonysyu
Copy link
Contributor Author

tonysyu commented Jan 25, 2013

@mdboom Good point on the category names. They'd be easy to change, and if nothing better jumps out, it's probably best just go with what's here.

As for automation, I think any mechanical work would be small compared to everything else. For example, I think most of the work is removing unnecessary customization, writing a good summary of the demo in the module docstring, combining/splitting examples from/into multiple files, etc.

@pelson
Copy link
Member

pelson commented Apr 18, 2013

Uh, oh - I'd forgotten about this big PR. Looks like there could be a couple of nasty merges as a result of this going stale. @tonysyu - are you going to be able to pick this up before release date (end of May)?

@tonysyu
Copy link
Contributor Author

tonysyu commented Apr 18, 2013

Thanks for pinging me on this. I should have some time to work on this (depending on the amount of work). Any hints on what changes may cause merge issues? Also, do the matplotlib-devs prefer merging changes from master (and resolving conflicts) or rebasing?

@mdboom
Copy link
Member

mdboom commented Apr 18, 2013

I generally prefer rebasing -- it makes the resulting history in the main project look cleaner. I hope the conflicts aren't too disastrous, but I haven't really looked.

@tonysyu
Copy link
Contributor Author

tonysyu commented Apr 18, 2013

Sounds good. I'll try rebasing tonight. Let's hope it's not too painful. :P

@pelson
Copy link
Member

pelson commented Apr 18, 2013

Let's hope it's not too painful. :P

I find that rebasing, when a conflict is identified with multiple commits, results in conflicts at each of the commits during rebase (I hope that makes sense). If you find this is the case, I'd be prepared to accept a merge in this PR, or alternatively a PR for each commit here (or you could squash the commits into just a few commits)...

Sorry for the brain dump! HTH

@mdboom
Copy link
Member

mdboom commented Apr 18, 2013

@pelson: Yes, that's true. When I run into that case (where a rebase causes conflicts at each step), I squash commits first, then rebase on master. I still think that's better than doing a merge in terms of the end result.

@tonysyu
Copy link
Contributor Author

tonysyu commented Apr 19, 2013

See PR #1924

@mdboom
Copy link
Member

mdboom commented Apr 19, 2013

Closed in favor of #1924.

@mdboom mdboom closed this Apr 19, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants