If Matplotlib were to do this, I think the approach would be to include the package as a git submodule so that there's no code duplication.

But, I'm also -1 on this 'cause Matplotlib would like to shed code from its core, not add to it. I've run into the bug where the packager doesn't pick up/install cycler, and I think the fix also needs to be on the packaging side.

cycler actually started life as a PR into Matplotlib (see #4258)! It was deemed useful enough that people wanted to be able to install it independently of Matplotlib, hence why it is in it's own package.

cycler has (fortunately) received very little work over the past few years (because it has just one job!). I also don't see there being any sort of change on either the cycler or Matplotlib sides that would cause any incompatibilities or require coordinated changes so while true in general, I do not think most of those advantages are persuasive here.

A bigger downside is that it is there are a number of isinstance checks in the implementation of cycler.Cycler (e.g. Cycler.__mul__) so if Matplotlib vendored cycler back you could end up with two Cycler objects that would not compose with each other.

I feel you on the less packages from a packagers point of view (I am a maintainer on a fair number of CF feedstocks), but as this dependency came in almost 4 years ago we have already paid the cost of getting it packaged by all of the major down-stream packagers. Reverting on that would likely be more hassle than maintaining the status quo.

I agree with @story645 on this and am going to close this issue.

@windelbouwman Given your question and that you are a member of rustpython, are you trying to get Matplotlib working on top of rust python (which would also imply that you have numpy working?)? Or are you packaging Matplotlib for some other stack? Either way, sounds like something cool!