~sircmpwn/core.sr.ht

34213d6d — Eli Schwartz 11 hours ago master 0.74.1
fix scripts disappearing after pyproject.toml conversion

In commit 1fbbcabb7c23516cf08f9581c5ea4876aa89326d, setup.py was reduced
to a stub loader for the pyproject.toml static metadata.

Without getting into whether it makes sense to programmatically vs.
statically define e.g. package_data, the scripts= argument to setup()
was never included in pyproject.toml and was removed from setup.py; this
broke the resulting installed package.

Restore this information.

Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Makefile: consistently use $(MODULE)

The target in question currently seems to not cause any issues, but it
does when switching dependents to the modern Python module structure,
where the build tools will build the package in a temporary virtual
environment.
pyproject.toml: properly define package data

Apparently even empty (i.e. non-Python) packages have to be defined as
packages, and the desired package data defined for each one. Also, as
long as `include-package-data` is true (the default), _everything_ will
be included, so set it to false.
Reduce setup.py to a stub

All configuration is now in pyproject.toml, all tooling set up to use
it. The stub remains for backwards compatibility. See 57ee342 and
https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html
flask.py: drop now-removed map.charset field
srht.markdown: bump version to 17
sections & asides should be treated similar to divs
time should support datetime
blockquotes & qs allow cite for citation
bdo allows overriding the direction
abbrs without titles aren’t terribly useful
allow any elements to have an ID

useful for ARIA labels & linking to particular elements/sections
allow more global attributes for accessibility
allow more elements for semantic, accessible, multilingual markup
flask: stop using deprecated code

The entire werkzeug.urls module has been deprecated for a while and was
removed entirely in werkzeug 3.0, which will be in the next Alpine
release.

See also:

- https://github.com/pallets/werkzeug/pull/2608/commits/53782a0a9721f4657ebac0ee5f30ebfbefba7d87
- https://github.com/pallets/werkzeug/pull/2768
Preparations for PEP440 support

Currrently, builds for patches are broken because the version numbers
generated for them are not valid according to PEP 440 [1].

Previous attempts [2] have shown that this cannot be solved in a single
commit (needs coordination with sr.ht-apkbuilds), so here is an attempt
at preparing this repo for a switch without breaking anything.

The grand plan is roughly:

1. Add a pyproject.toml without touching setup.py (this commit)
2. Switch APKBUILD from `python setup.py build` to `python -m build`
3. Reduce setup.py to a stub, encoding all relevant information in
   pyproject.toml

With this commit, this module can be build with both `python setup.py
build` and `python -m build`, if, _and only if_ the PKGVER environment
variable is set, which is true for all our tooling.

As the version passed in via the environment is still not
PEP440-compatible, packaging non-tagged versions will remain broken
until step three above is executed.

The .gitattributes and .git_archival files are included for the future
setup. Since packages are built from `git-archive` tarballs, the commit
information has to be transported into the tarballs. The setuptools-scm
package specifies a mechanism for this [3]. Note, that in order to avoid
a hilarious bug [4] the checked in `.git_archival.txt` differs from the
template found in the documentation. The git version on git.sr.ht is new
enough that the `describe-name` will be expanded, and if present it is
the only information that setuptools-scm really requires.

[1] https://peps.python.org/pep-0440
[2] https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/50784
[3]: https://setuptools-scm.readthedocs.io/en/latest/usage/#git-archives
[4]: https://github.com/pypa/setuptools_scm/issues/806
Do not inject dir=auto using BeautifulSoup
srht.webhook: missed an import
.builds/alpine.yml: update to 3.19
srht.webhook: fix SQLalchemy usage
Next