Repository navigation
[pre-commit.ci] pre-commit autoupdate - #124
Conversation
b1bf506 to
cf3e10c
Compare
cf3e10c to
b9c2b1e
Compare
|
Hello @HDembinski, I don't know if you have been seeing these bot updates. There are some issues to sort out / modernise. Could you let us (org) know what your plans for the package are? |
|
@eduardo-rodrigues Could you try to get @afedynitch on board as a new maintainer? They are the one of the main users of this package. |
|
As for your question, I don't have any plans for this package. |
|
Morning Hans. I can certainly try, but if you have @afedynitch's contact and could put me in touch via a little email, that will help. As for the future of the package: similarly to other cases, we have to be careful and put the little time we have free on things that are demanded. If a package becomes unmaintained or unused we have to bite the bullet at some point and deprecate and archive it, eventually. You've probably seen some related discussions in the past months on the admins list. Let's then see what we manage and we then decide. Thanks. |
b9c2b1e to
fbb0a78
Compare
|
I could help maintaining this package. But is the anything that supersedes it - like a different project also writing pyhepmc from Python? Or what is the issue? |
Hello @afedynitch, that would be super, especially if you are a user of the package. I'm just trying to help and am myself not in need (at least so far). You experts should tell but I believe nothing supersedes it per se, hence the interest in getting this package to plain maintenance mode. I see some tasks/issues and some more work to get to such a level. There would also be some trivial admin actions to take - ensure an update of maintainers on PyPI (I see Andy Buckley in https://pypi.org/project/pyhepmc/ but for sure he is not a maintainer), we should move it under the PyPI Scikit-HEP org as we do for our packages, etc. These things are no urgency, so no worries that it goes in the background of your nominal work ;-). I would imagine that it won't take much time for an expert to get this up-to-date, and then work should be small and only every now and then. For sure we're both happy to add you as a collaborator or whatever is needed for you to act. Kindly advise. |
fbb0a78 to
f16efd5
Compare
|
Hello @afedynitch, will you then be able to get started getting the library/repo up to speed, as per the exchanges and comments above? That would be great. I have been flooded with work but will try and reply to your email asap. Apologies for the unusual delay. |
f16efd5 to
2479990
Compare
updates: - [github.com/astral-sh/ruff-pre-commit: v0.16.5 → v0.17.2](astral-sh/ruff-pre-commit@v0.16.5...v0.17.2) - [github.com/pre-commit/mirrors-clang-format: v23.1.0 → v23.1.3](pre-commit/mirrors-clang-format@v23.1.0...v23.1.3) - [github.com/pre-commit/mirrors-mypy: v2.3.1 → v2.4.0](pre-commit/mirrors-mypy@v2.3.1...v2.4.0) - [github.com/henryiii/validate-pyproject-schema-store: 2026.08.29 → 2026.10.23](henryiii/validate-pyproject-schema-store@2026.08.29...2026.10.23)
2479990 to
1dbf7c9
Compare
Preserve deferred stream ownership while distinguishing file openers, make optional annotations explicit, and remove interactive debug traps. Use the pyhepmc opener explicitly in I/O tests. Assisted-by: Codex:GPT-6
|
Hello @afedynitch I assume that you have karma to merge as well, but otherwise let us know. At this point maybe we can get rid of Python 3.19 and bump up? |
|
Hi. Allow me a person opinion - scoped PRs are much better and it seems you're going well beyond the pre-commit here. I would have made separate PRs to retired 3.9 and make packing improvements and alike. Then a rebase would do for actual pre-commit issues here? Anyway, glad that you're picking this up. |
|
I agree with, the reason is that CI is not passing for a couple of reasons. I'll remove the modernization from this PR to keep it scoped and then push to main even if the CI doesn't pass, and then do the modernization PR straight after that to fix CI and some issue. |
fd0ad0a to
bfb1408
Compare
updates: