Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

musharafmaqbool
Copy link

@musharafmaqbool musharafmaqbool commented Sep 3, 2025

PR summary

PR checklist

Creates fully-pinned-v3.6.x.txt with exact dependency versions to ensure 
reproducible testing environments when working on backport branches.

This addresses the need for consistent dependency versions during bug-fix
testing and reduces issues with transitive dependency conflicts.

Fixes matplotlib#23548
…nts-file-for-v3.6.x-bug-fix-branches

## Summary
Added a fully pinned requirements file to help with testing on v3.6.x bug-fix branches. This should make it easier to get consistent test environments when working on backports.

## What's included
- Core matplotlib dependencies with exact versions
- Common GUI backends (Qt, Cairo, web)
- Testing tools like pytest
- Build dependencies
- Transitive deps that sometimes cause version conflicts

## Why this helps
When testing old versions or backporting fixes, dependency resolution can be a pain. Having everything pinned means we can quickly set up an environment that actually works instead of spending time debugging version conflicts.

The versions here are from around the 3.6.x timeframe so they should all play nicely together.

Addresses matplotlib#23548
@musharafmaqbool
Copy link
Author

Hi! This is my first contribution to matplotlib, so please let me know if I need to adjust anything. Happy to make changes based on feedback.

@tacaswell
Copy link
Member

Thank you for your work. Despite this matching my initial suggestion closely, I think we want to have some more thought about how this looks.

Would it be better to set the pins in the requirement files on the bug-fix branches (which does make the merge up more annoying, but I think we just have to add a git checkout origin/main -- [requirements files] to the local process before opening the PR on GH), but means that we do not have to carry around an ever growing number of versioned requirements files.

If we are going to go with the fully-pinned* approach I would start with the currently version and then let it naturally start being used with the 3.11 release (the next one) and not worry about retroactively generating them for old releases. Should this be managed by the depondabot?

Finally, per the discussion in #30432 the simplest fix maybe to document to use the pixi (and uv) functionality to solve environments "as of" some date and let that provide the cap. Those tools did not exist when I opened #23548 , documenting them may be enough.


How did you select the transitive dependencies to pin? By what metric are they they problematic ones?

Why did you pick 3.6 to start with rather than 3.10 (the currently active bug-fix version)?

Once we have this file, how do you propose we keep this up-to-date and manage using it on the backport branches?

@musharafmaqbool
Copy link
Author

@tacaswell Thanks for the feedback!

On dependency selection: I'll be honest - I made some educated guesses based on what I thought would be compatible with 3.6.x, but I didn't use a systematic approach like pip freeze from a clean environment. That's probably not the best way to do this.

On version choice: I picked 3.6 because that's what the original issue mentioned, but you're absolutely right that starting with the current active bug-fix version (3.10) makes more sense. Should I switch to 3.10.x instead?

On the approach: Your suggestion about using git checkout + pip freeze sounds much better than what I did. Would you prefer I:

  1. Update this to target 3.10.x with a proper pip freeze approach, or
  2. Close this PR and let someone with more experience handle it?

I'm new to this workflow so happy to learn the right way to do it! The pixi and uv tools you mentioned are new to me but I can research those if that's the preferred direction.

Thanks for taking the time to explain the bigger picture - this is really helpful for understanding how matplotlib handles dependencies.

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.

2 participants