matplotlib / matplotlib.org

Matplotlib is a comprehensive library for creating static, animated, and interactive visualizations in Python.

Check out our home page for more information.

Matplotlib produces publication-quality figures in a variety of hardcopy formats and interactive environments across platforms. Matplotlib can be used in Python scripts, Python/IPython shells, web application servers, and various graphical user interface toolkits.

Install

See the install documentation, which is generated from /doc/install/index.rst

Contribute

You've discovered a bug or something else you want to change — excellent!

You've worked out a way to fix it — even better!

You want to tell us about it — best of all!

Start at the contributing guide!

Contact

Discourse is the discussion forum for general questions and discussions and our recommended starting point.

Our active mailing lists (which are mirrored on Discourse) are:

• Users mailing list: [email protected]
• Announcement mailing list: [email protected]
• Development mailing list: [email protected]

Gitter is for coordinating development and asking questions directly related to contributing to matplotlib.

Citing Matplotlib

If Matplotlib contributes to a project that leads to publication, please acknowledge this by citing Matplotlib.

A ready-made citation entry is available.

matplotlib.org's Issues

Do we need to be able to run Caddy from a checkout directly?

Initially, I wrote the Caddyfile to be able to be run locally. With the Ansible config added, we have a couple redundancies defining, e.g., the list of subrepos to clone and serve. We can remove that redundancy by making the Caddyfile a template, but then it can't be run directly.

I recently came across ansible-bender, so I think we could maybe point local testing there (it takes an Ansible config and applies it to a container instead of your configured hosts.)

Server naming scheme

We don't have many servers (nominally 1 if load allows it), but if we need to provision a bigger one, and destroy the old, it'd be good to have a reasonable naming scheme. I've found this blog post which seems reasonable. It is for a far higher count of servers than we need, so we can skip a few items, but I think something like the following:

• Servers are named <prefix>.matplotlib.org in A records.
• Servers get a functional CNAME alias (e.g., web01.matplotlib.org). Since we have few servers, I suggest ignoring the geographical and environmental prefixes given in the post.
• matplotlib.org is a CNAME to the functional CNAME of a server.

There are several suggested word pools, but as it's fairly neutral, easy-to-remember, and not-too-difficult-to-spell, I'm going to suggest that we use Planets in our Solar System as <prefix>.

Bug: There is some problem with light/dark theme

https://matplotlib.org/devdocs/

On this domain page, if I switch between light and dark themes, in some of the sections only the font colour changes without any change in the background, which makes it impossible to read.

Web browser: Brave
Default browser theme: Dark

Should web hooks run on a separate domain?

When initially spinning up the droplet, I put it on do.matplotlib.org so we could test load a bit. I also configured all web hooks using that domain.

Now that matplotlib.org is pointing to the droplets, I modified Caddy to serve the same thing from both domains so that nothing breaks. However, that's a bit redundant, and we don't really need CF to be CDN'ing things twice (though I don't expect anyone to be accessing the duplicated subdomain.)

We can update the web hooks to point to matplotlib.org easily, but I wonder if we should leave them on a separate domain still? They'd still be served by the same server, but that would silo off the paths just in case we needed them (though that's unlikely).

redirect blog to scientific python blog

    Should we add redirects to the server for the existing blog?

Originally posted by @QuLogic in matplotlib/mpl-brochure-site#62 (comment)

Do we need metrics to be (semi-)public?

Metrics for monitoring are currently only available on the machine, so you need to SSH there and forward the port to view anything. We could make this (semi-)public by forwarding through Caddy (on a subdomain?). Grafana supports OAuth via GitHub, so we could then set up login via a team.