Hatchling does not support dynamic description, it needs to be stated
explicitly.
---
 pyproject.toml | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/pyproject.toml b/pyproject.toml
index a2a74ac..3443ac5 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -4,6 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "offpunk"
[message trimmed]

On 2025-03-09 19:55, Ploum wrote:
>Thanks for that patch. I merged it and added the secret part.
>
>But I can’t really test it until there’s a release. One option would be
>to remove the "if git_ref" code to test it, acknowledging that the Pypi
>2.6 would not be the true 2.6.

v2.6 is already uploaded manually, and PyPI will not overwrite existing 
versions.

>
>Le 25 mar 08 06:12, Anna “CyberTailor” a écrit :
>>It needs UV_PUBLISH_TOKEN environment variable configured:
>>https://docs.astral.sh/uv/guides/package/#publishing-your-package

On 2025-03-08 19:32, Ploum wrote:
>Hi Anna,
>
>Could you explain a bit more the context? If I understand this
>correctly, you would like the pypi package to be published automatically
>when pushing a new release?

Yes. One person was granted publishing access to PyPI after my initial 
call:
https://lists.sr.ht/~lioploum/offpunk-packagers/%3CZVefWLKUHk_QgL_A@sysrq.in%3E

But I checked PyPI yesterday, and there were no uploads for a year.

Also manual uploading is not the best choice for poorly vetted

Hi,

I see that you're the upstream maintainer for unmerdify.

Since unmerdify.py is not included in the wheel package and is only used 
from a repo checkout, and there's also a `ModuleNotFoundError` check, I 
can guess that distro maintainers are expected to package unmerdify.

So my questions are:

- Are the single-file and the regular version of unmerdify 
   interchangeable? Will they be kept in sync between each other?

- Are you going to eventually tag releases for unmerdify?

Hi,

I see that you're the upstream maintainer for unmerdify.

Since unmerdify.py is not included in the wheel package and is only used 
from a repo checkout, and there's also a `ModuleNotFoundError` check, I 
can guess that distro maintainers are expected to package unmerdify.

So my questions are:

- Are the single-file and the regular version of unmerdify 
   interchangeable? Will they be kept in sync between each other?

- Are you going to eventually tag releases for unmerdify?

Context: https://github.com/urllib3/urllib3/issues/3020
---
 netcache.py | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/netcache.py b/netcache.py
index da66e7a..c43206b 100755
--- a/netcache.py
+++ b/netcache.py
@@ -11,6 +11,7 @@ import ssl
 import sys
 import time
 import urllib.parse
+import warnings
[message trimmed]

It needs UV_PUBLISH_TOKEN environment variable configured:
https://docs.astral.sh/uv/guides/package/#publishing-your-package

Commented the publishing part for now, because it requires actual
secrets.
---
 .build.yml | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/.build.yml b/.build.yml
index bac87f3..d9ec6ff 100644
--- a/.build.yml
+++ b/.build.yml
@@ -1,10 +1,24 @@
[message trimmed]

Could be used with test runners like Tox.

See: https://peps.python.org/pep-0735/
---
 pyproject.toml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/pyproject.toml b/pyproject.toml
index cde9e8a..a2a74ac 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -45,6 +45,12 @@ netcache = "netcache:main"
 ansicat = "ansicat:main"
 opnk = "opnk:main"
[message trimmed]

License classifiers and "project.license" subkeys are now deprecated.

SPDX expressions should be used instead:
https://peps.python.org/pep-0639/
---
 pyproject.toml | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/pyproject.toml b/pyproject.toml
index 2b8af81..cde9e8a 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -1,5 +1,5 @@
 [build-system]
[message trimmed]

The first two patches are pyproject.toml metadata updates.

Patch #3 is untested and needs polishing, exchanging secrets etc.

Patch #4 fixes a minor annoyance for LibreSSL users.