Future of this package

[lassoan]

This package is very useful, thanks a lot for providing it! I would like to use it in a large open-source project (3D Slicer) but I'm not sure if I can rely on it in the long term, due to the followings:

1. It seems that there have been no new tags (and releases on PyPI) for almost two years
2. It is still not a native Python3, but patched using 2to3
3. Large backlog of open issues and 10+ open pull requests

Could somebody provide information about current status and future plans for this package?

I see that there have been some recent commits, so I still have some hope. Thanks in advance!

[jaraco]

Is "metadata" the classifiers in setup.py for this package?

Actually, I'm speaking of the Requires-Python metadata.

And now I see this project isn't declaring that metadata right now. That's not good. That means that a user installing comtypes on Python 2.7 or 3.6 will still be offered the latest release (and all prior releases):

 ~ [1] @ pip download --python-version 2.7 --no-deps comtypes
Collecting comtypes
  Downloading comtypes-1.4.3.zip (229 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 229.6/229.6 kB 2.7 MB/s eta 0:00:00
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Installing backend dependencies ... done
  Preparing metadata (pyproject.toml) ... done
Saved ./comtypes-1.4.3.zip
Successfully downloaded comtypes

We'll want to get that fixed ASAP and get a release out. PR incoming.

So, I realized that it might be not possible to determine the supported Python3.Y version from the PyPI metadata for this package. Is that correct?

That is correct. The classifiers are essentially useless and I recommend against using them except maybe to declare the major Python version, which today is just "3" and there's no likelihood of "4", so I just omit it.

[junkmd]

I released comtypes==1.4.4, including packaging metadata fix. https://pypi.org/project/comtypes/1.4.4/

[nanonyme]

If there are versions out there that claim Python 2 support but don't really support it, consider yanking them.

[junkmd]

I plan to release comtypes==1.4.6, the final version to support Python 3.7, in early August.

[junkmd]

I believe that yanking should be done for more critical situations, such as when a vulnerability is discovered or when the package becomes unusable at all.

If we yank versions solely because python_requires was not specified and might allow installation on unsupported Python versions, it could unnecessarily confuse users who are currently using those versions.

[junkmd]

An idea that might effectively clarify which versions of Python this package supports:

As previously discussed, "classifiers are essentially useless", adding or removing the 'Programming Language :: Python :: 3.x' classifier every time this package drops support for older versions or starts supporting newer ones isn't ideal from a maintainability perspective.

I came across this comment. In that discussion, it was pointed out that, although it's not as simple as setting up other badges, we can use a query to obtain the Requires-Python metadata and display it as a badge.

A badge like this might be useful:

Any opinions would be appreciated.

[jaraco]

+1 to using Requires-Python and reflecting that in a badge.

[nanonyme]

That is correct. The classifiers are essentially useless and I recommend against using them except maybe to declare the major Python version, which today is just "3" and there's no likelihood of "4", so I just omit it.

There is one point of classifiers which is basically "project is has CI testing against these Python versions". Then again, people typically add versions even if there's coverage gaps for interpreter versions... But the main point is that it may work on newer, it's just not been tested. Requires-Python is semantically different and just means you must not install on older than given version.

[junkmd]

A Requires-Python badge would also be effective, but what we might additionally need is a badge that shows the Python versions for which tests have passed in the CI pipeline.

While researching a way to generate such a badge, I came across https://github.com/40ants/github-actions. However, it’s not as simple as the badge based on 'classifiers', like .

rendered badge image


[junkmd]

We have identified cases where comtypes may not work in Python 3.13, potentially due to changes in the implementation of ctypes, without modifying codebases or fixing bugs in CPython. Let's discuss this in #618.

[junkmd]

To support Python 3.13, version 1.4.8 includes changes to metaclass initialization.

To prevent comtypes from breaking due to future ctypes changes, tests to ensure the functionality of the metaclasses used by this project were submitted as a PR (https://github.com/python/cpython/pull/125881) on the cpython side and have been merged.