Updating for Python 3.12-3.14

100 views
Skip to first unread message

Matthew Stidham

unread,
Sep 26, 2025, 2:06:21 PMSep 26
to openpyxl-users
I am using openpyxl at work for a project, and noticed how its setup.py and tox.ini files were out of date. I removed old versions of Python, which will be unsupported next month, and added 3.12 through 3.14. I ran tox on Python versions 3.10 through 3.14 on my computer, fixed a few errors that appeared, and now tox runs cleanly on all five versions. I have the changes ready, so this project can be up to date for the newest release of Python, which is coming in a few weeks.

Heptapod won't let me fork the repository, so I sent in an access request.

I haven't updated the documentation; someone else will still need to do that, but at least the code will work for people on the latest version of Python now.

Please let me know if there are any additional steps I need to take to complete this process.

Thank you!

Charlie Clark

unread,
Sep 29, 2025, 5:15:09 AMSep 29
to openpyxl-users
On 26 Sep 2025, at 20:06, Matthew Stidham wrote:

Hiya,

> I am using openpyxl at work for a project, and noticed how its setup.py and
> tox.ini files were out of date. I removed old versions of Python, which
> will be unsupported next month, and added 3.12 through 3.14. I ran tox on
> Python versions 3.10 through 3.14 on my computer, fixed a few errors that
> appeared, and now tox runs cleanly on all five versions. I have the changes
> ready, so this project can be up to date for the newest release of Python,
> which is coming in a few weeks.

Thanks for looking into this project has been running against ≥ 3.13 for a while - locally with Python 3.14-devel. There are some unrelated lxml issues which have been fixed elsewhere.

Python's shift to yearly releases and fairly rapid deprecation of older versions is not helpful, not just for me but for many using the software. And, as long as compatibility isn't broken, I don't see the need to remove any.

There haven't been any significant changes to 3.1 since the last release so no real need for a release just because of new Python releases but I guess we'll have to revisit that at the latest when Python 3.14 is released. The best thing is going to be removing named support for specific releases so that installers won't complain.

> Heptapod won't let me fork the repository, so I sent in an access request.

I'll approve that shortly.

> I haven't updated the documentation; someone else will still need to do
> that, but at least the code will work for people on the latest version of
> Python now.

There's another ticket related to this, but updating the docs should always been part of any PR. There are two separate tox environments that help in this respect.

> Please let me know if there are any additional steps I need to take to
> complete this process.

No, nothing else, it's just the library hasn't been my main focus for a good while now and the proposed changes, some of which are great, in 3.2 need some work before it can be released.

Charlie

--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Sengelsweg 34
Düsseldorf
D- 40489
Tel: +49-203-3925-0390
Mobile: +49-178-782-6226

Matthew Stidham

unread,
Sep 29, 2025, 9:13:51 AMSep 29
to openpyxl-users
Awesome, thank you. I've put my changes into a branch and am trying to push my changes to a new branch on heptapod. I am receiving the error message

remote: You are not authorised to publish changesets

I'm authenticating with my username and password, and I am pushing with the command hg push --new-branch.

My SSH key is added to my account from this desktop, but it is not recognizing it.

I'm new to heptapod and mercurial, I almost always use git. What am I doing wrong?

Charlie Clark

unread,
Sep 29, 2025, 9:25:56 AMSep 29
to openpyxl-users

On 29 Sep 2025, at 15:13, Matthew Stidham wrote:

Hi,

Awesome, thank you. I've put my changes into a branch and am trying to push
my changes to a new branch on heptapod. I am receiving the error message

remote: You are not authorised to publish changesets

I'm authenticating with my username and password, and I am pushing with the
command hg push --new-branch.

My SSH key is added to my account from this desktop, but it is not
recognizing it.

I'm new to heptapod and mercurial, I almost always use git. What am I doing
wrong?

I don't think you're doing anything really wrong but Heptapod is set up to use topics for changes rather than branches. These look and feel like branches but the internals are different but don't ask me about the details and only try to read the docs if you're prepared to try and understand them.

You'll need to make sure you have the extension installed - I think it's now standard with Mercurial but also enabled for the repository: this is pretty easy in Tortoise or the command line.

You then need to switch branches to the one you based your changes on, create a topic and make the changes – you can't really merge from your branch, because that would sort of create it. You can then delete the branch you created and it should be possible to push the topic. Once you have a topic you use it like a normal branch, but Mercurial will hide it automatically once I have merged it.

I know that changing VCSes is always annoying, but once you've got it set up, you'll probably need to change nothing.

Matthew Stidham

unread,
Sep 29, 2025, 11:31:23 AMSep 29
to openpyxl-users
Thanks, I figured out how to do that. I have submitted a merge request with my updates.

The pipeline still tests on 3.8 and 3.9, which are impossible to test on since the Docker containers from these are no longer available from Heptapod. I don't have permission to update the pipeline. The full required change list is:
  • Remove test-python38 and test-python39
  • Enable testing on py313
  • Enable testing on py314

Thanks for all your help!

Matthew Stidham

unread,
Oct 1, 2025, 10:23:12 AMOct 1
to openpyxl-users
I was able to merge your changes to my topic, but it wouldn't push to heptapod. I tried both ChatGPT and the documentation to no avail. I don't know why, and I don't care enough about Mercurial to learn how to do it properly at this point. You made all the necessary changes in my branch already, so once a new version is released, it will work for my team. Thank you. We will update our dependencies and test again when the new version is released. Thank you.

Charlie Clark

unread,
Oct 1, 2025, 12:05:13 PMOct 1
to openpyxl-users

On 1 Oct 2025, at 16:23, Matthew Stidham wrote:

Hiya,

I was able to merge your changes to my topic, but it wouldn't push to
heptapod.

Looking at the log it looks like you merged into the default branch. This is unnecessary as the topic would be merged automatically into the correct branch once I approve it.

I tried both ChatGPT and the documentation to no avail.

I've never worked with ChatGPT but Mistral seemed to come up with a workable solution. Well, it worked without errors. I'll just have to see if anything is broken!

For info, this is what it came up with:

"""
Merging a topic into the wrong branch in Mercurial can be undone, but the approach depends on whether you've already pushed the changes or not. Here’s how to handle it:

Find the revision of the merge:
Run hg log to identify the changeset ID of the incorrect merge.

If the merge has been pushed
If the merge is already public (pushed to a shared repository), rolling back isn’t safe because it rewrites history. Instead, you can reverse the merge:

Create a reverse merge commit:
Use the hg revert command to undo the changes introduced by the merge:

hg revert --all --rev "parent of the merge"
hg commit -m "Revert accidental merge of topic into wrong branch"

Replace "parent of the merge" with the changeset ID of the commit before the merge.

Merge the topic into the correct branch:
Now, merge the topic into the intended branch:

hg update correct_branch
hg merge topic_branch
hg commit -m "Merge topic into correct branch"

"""

I don't know why, and I don't care enough about Mercurial to learn how to do it
properly at this point.

You might want to reconsider that sentence as if I'd written it about your project… ;-)

You made all the necessary changes in my branch
already, so once a new version is released, it will work for my team. Thank
you. We will update our dependencies and test again when the new version is
released. Thank you.

Charlie

Matthew Stidham

unread,
Oct 1, 2025, 12:42:22 PMOct 1
to openpyxl-users
Thanks, I spent an hour on this morning and was getting really frustrated. Openpyxl looks like a great library for people working with excel files, and there are a number of features to this library which are not duplicated with any other library. We will test this very soon and hopefully it will solve our problems. If I work on this further I will look for a proper course to learn the differences of mercurial on  youtube to familiarize myself with the commands.

I really appreciate your help.
Matthew

Charlie Clark

unread,
Oct 1, 2025, 1:11:00 PMOct 1
to openpyxl-users
On 1 Oct 2025, at 18:42, Matthew Stidham wrote:

> Thanks, I spent an hour on this morning and was getting really frustrated.
> Openpyxl looks like a great library for people working with excel files,
> and there are a number of features to this library which are not duplicated
> with any other library. We will test this very soon and hopefully it will
> solve our problems. If I work on this further I will look for a proper
> course to learn the differences of mercurial on youtube to familiarize
> myself with the commands.

And I spent a couple of hours pissing around with Sphinx just so that I could insert the minimum Python version… and then also have access to rendered versions of files from the project. Sometimes you've just got to do this.

I don't think there is much difference between Mercurial and Git; I remember Tres Seaver saying we have to choose which VCS system to hate!

But the Heptapod workflow is different and not intuitive, especially the use of topics instead of forks. But I'm infinitely grateful for Octobus for offering it to us and other important Python projects after Atlassian decided to drop support for Mercurial – this can happen to any of our favourite tools at any time, so be prepared to switch tool or hosting provider.

I thought someone was working on updating the documentation to reflect this but I may be mistaken. This is something that we could all benefit from but it's often best written by someone who's just had to learn the hard way!
Reply all
Reply to author
Forward
0 new messages