% git grep -B 5 DIST_SUBDIR= -- `git grep --max-depth=2 -l cargo`
graphics/librsvg2-rust/Makefile-PORTVERSION=    2.54.5
graphics/librsvg2-rust/Makefile-PORTREVISION=   6
graphics/librsvg2-rust/Makefile-CATEGORIES=     graphics gnome
graphics/librsvg2-rust/Makefile-MASTER_SITES=   GNOME
graphics/librsvg2-rust/Makefile-PKGNAMESUFFIX=  2-rust
graphics/librsvg2-rust/Makefile:DIST_SUBDIR=    gnome2
--
lang/rust-bootstrap/Makefile-CATEGORIES=        lang
lang/rust-bootstrap/Makefile-MASTER_SITES=      https://static.rust-lang.org/dist/
lang/rust-bootstrap/Makefile-PKGNAMEPREFIX=     ${FLAVOR:S/_/-/g}-
lang/rust-bootstrap/Makefile-PKGNAMESUFFIX=     -bootstrap
lang/rust-bootstrap/Makefile-DISTNAME=  ${PORTNAME}c-${PORTVERSION}-src
lang/rust-bootstrap/Makefile:DIST_SUBDIR=       rust

Neither of these currently use USES=cargo.

We're safe, no exp-run needed:

% git grep -B 5 PORTVERSION= -- `git grep --max-depth=2 -l pep517`
CHANGES-  with EXTRACT_ONLY.
CHANGES-
CHANGES-  A simple example:
CHANGES-
CHANGES-    PORTNAME=     bar
CHANGES:    PORTVERSION=  1.0
--
databases/py-aiosqlite/Makefile-PORTNAME=       aiosqlite
databases/py-aiosqlite/Makefile:PORTVERSION=    0.18.0
--
devel/mercurial/Makefile-PORTNAME=      mercurial
devel/mercurial/Makefile:PORTVERSION=   6.3.2
--
devel/nox/Makefile-PORTNAME=    nox
devel/nox/Makefile:PORTVERSION= 2022.11.21
--
devel/py-RPyC/Makefile-PORTNAME=        rpyc
devel/py-RPyC/Makefile:PORTVERSION=     5.3.1
--
devel/py-argh/Makefile-PORTNAME=        argh
devel/py-argh/Makefile:PORTVERSION=     0.28.1
--
devel/py-build/Makefile-PORTNAME=       build
devel/py-build/Makefile:PORTVERSION=    0.10.0
--
devel/py-find-libpython/Makefile-PORTNAME=      find-libpython
devel/py-find-libpython/Makefile:PORTVERSION=   0.3.0
--
devel/py-flit-core/Makefile-PORTNAME=   flit-core
devel/py-flit-core/Makefile:PORTVERSION=        3.8.0
--
devel/py-flit/Makefile-PORTNAME=        flit
devel/py-flit/Makefile:PORTVERSION=     3.8.0
--
devel/py-installer/Makefile-PORTNAME=   installer
devel/py-installer/Makefile:PORTVERSION=        0.6.0
--
devel/py-interface-meta/Makefile-PORTNAME=      interface-meta
devel/py-interface-meta/Makefile:PORTVERSION=   1.3.0
--
devel/py-jsonschema/Makefile-PORTNAME=  jsonschema
devel/py-jsonschema/Makefile:PORTVERSION=       4.17.3
--
devel/py-lazy_loader/Makefile-PORTNAME= lazy_loader
devel/py-lazy_loader/Makefile:PORTVERSION=      0.1
--
devel/py-packaging/Makefile-PORTNAME=   packaging
devel/py-packaging/Makefile:PORTVERSION=        23.0
--
devel/py-pathspec/Makefile-PORTNAME=    pathspec
devel/py-pathspec/Makefile:PORTVERSION= 0.11.1
--
devel/py-pdm-pep517/Makefile-PORTNAME=  pdm-pep517
devel/py-pdm-pep517/Makefile:PORTVERSION=       1.1.0
--
devel/py-pdm/Makefile-PORTNAME= pdm
devel/py-pdm/Makefile:PORTVERSION=      2.2.1
--
devel/py-pep517/Makefile-PORTNAME=      pep517
devel/py-pep517/Makefile:PORTVERSION=   0.13.0
--
devel/py-pyls-black/Makefile-PORTNAME=  pyls-black
devel/py-pyls-black/Makefile:PORTVERSION=       0.4.7
--
devel/py-pyproject_hooks/Makefile-PORTNAME=     pyproject_hooks
devel/py-pyproject_hooks/Makefile:PORTVERSION=  1.0.0
--
devel/py-pytest-metadata/Makefile-PORTNAME=     pytest-metadata
devel/py-pytest-metadata/Makefile:PORTVERSION=  2.0.4
--
devel/py-pytoolconfig/Makefile-PORTNAME=        pytoolconfig
devel/py-pytoolconfig/Makefile:PORTVERSION=     1.2.5
--
devel/py-requirementslib/Makefile-PORTNAME=     requirementslib
devel/py-requirementslib/Makefile:PORTVERSION=  2.2.3
--
devel/py-typing-extensions/Makefile-PORTNAME=   typing-extensions
devel/py-typing-extensions/Makefile:PORTVERSION=        4.4.0
--
devel/py-virtualenv/Makefile-PORTNAME=  virtualenv
devel/py-virtualenv/Makefile:PORTVERSION=       20.20.0
--
finance/py-financedatabase/Makefile-PORTNAME=   financedatabase
finance/py-financedatabase/Makefile:PORTVERSION=        2.0.9
--
print/py-pydyf/Makefile-PORTNAME=       pydyf
print/py-pydyf/Makefile:PORTVERSION=    0.5.0
--
print/py-weasyprint/Makefile-PORTNAME=  weasyprint
print/py-weasyprint/Makefile:PORTVERSION=       58.0
--
security/py-securesystemslib/Makefile-PORTNAME= securesystemslib
security/py-securesystemslib/Makefile:PORTVERSION=      0.26.0
--
security/py-tuf/Makefile-PORTNAME=      tuf
security/py-tuf/Makefile:PORTVERSION=   2.1.0
--
sysutils/py-docker/Makefile-PORTNAME=   docker
sysutils/py-docker/Makefile:PORTVERSION=        6.0.1
--
textproc/py-pyphen/Makefile-PORTNAME=   pyphen
textproc/py-pyphen/Makefile:PORTVERSION=        0.13.0
--
textproc/py-sphinx/Makefile-PORTNAME=   sphinx
textproc/py-sphinx/Makefile:PORTVERSION=        5.3.0
--
textproc/py-tomli/Makefile-PORTNAME=    tomli
textproc/py-tomli/Makefile:PORTVERSION= 2.0.1
--
www/py-dj40-django-auth-ldap/Makefile-PORTNAME= django-auth-ldap
www/py-dj40-django-auth-ldap/Makefile:PORTVERSION=      4.1.0
--
www/py-dj41-django-auth-ldap/Makefile-PORTNAME= django-auth-ldap
www/py-dj41-django-auth-ldap/Makefile:PORTVERSION=      4.1.0
--
www/py-dj41-django-cors-headers/Makefile-PORTNAME=      django-cors-headers
www/py-dj41-django-cors-headers/Makefile:PORTVERSION=   3.14.0
--
www/py-dj41-django-rich/Makefile-PORTNAME=      django-rich
www/py-dj41-django-rich/Makefile:PORTVERSION=   1.5.0
--
www/py-django-auth-ldap/Makefile-PORTNAME=      django-auth-ldap
www/py-django-auth-ldap/Makefile:PORTVERSION=   4.1.0
--
www/py-fastapi/Makefile-PORTNAME=       fastapi
www/py-fastapi/Makefile:PORTVERSION=    0.92.0

Haha beat me to it! Also had this sitting locally, checking that existing PORTREVISION uses didn't break (all good there).

In D38802#889186, @fuz wrote:

Auto-generating pycode files is off the cards, so this change is no longer needed.

In D39004#888542, @jbeich wrote:

Looks incomplete. patch-setup.py was adjusting manpage location, obsoleted by 003a571d1d65. To fix polkit action may require either expanding USES=uniquefiles:dirs (implied by USE_PYTHON=concurrent) to handle the conflicting file/directory or adjusting ${TMPPLIST} from post-patch gated by PKGNAMESUFFIX.

In D39004#888526, @mandree wrote:

So the default-python based package can additionally install everything under plain names, or there can be another package that depends on the default python's and adds symlinks to the relevant entry points, commands, documentation, without all those 39 and -3.9 names.

devel/meson-python: patch out hardcoded meson invocations

devel/meson-python: add BINARY_ALIAS

Doing it this way, when building meson-python on a non-default Python, fails because literally bin/meson is expected, not bin/meson-${PYTHON_VER}.

devel/meson: bump PORTREVISION for package change

add USE_PYTHON=concurrent and remove polkit action, as it file conflicts and doesn't work properly here anyway

devel/meson-python: adjust dependency lines

meson.mk: use entry point in dependency specifier, PKGNAME changes when not default FLAVOR

meson.mk: FLAVOR was apparently not needed here

In D34739#883877, @mandree wrote:

You are distracting again, and your arguments are not relevant. Functions can have arguments, so you can cater for the few differences. A Python port that isn't CPython need not call the refactored function at all.

In D34739#883869, @mandree wrote:

So, the trigger is redundantly duplicated across all Python versions. This is bad style and error-prone.

Please refactor this to a common script (either we keep it in Tools/ or else in a separate port), and just run it from the trigger (which has the port-specific %%PYTHON_*%% variables, with the necessary arguments.
That also makes it amenable to separate testing and maintenance independent of the Python package.

yeet bytecode from USE_PYTHON=distutils because to hell with them

now that we apparently have to appease non-fatal errors not part of the build, as if package builders are sentient beings

For those who've lived under a rock, I'm not under mentorship.

only allow select directories under hier(7)

lang/cjs: pull in commit from cjs to fix clang-15 build

• silence bytecode compile/delete messages, except for errors
• add CHANGES and UPDATING entries for SUB_LIST and trigger

use more SUB_LIST entries on triggers

Obviated in favour of D34739

Obviated in favour of D34739

individualise between the different interpreters/distributions

pip is unacceptably heavy dependency-wise and cannot be bootstrapped (in that circular dependencies will result) how installer, build et al can. It is also not intended for "system" use. installer currently does not track bytecode in RECORD or anywhere else.

Most others package bytecode, but again as a crutch due to lack of a trigger function that we have. Most others also don't have the strict/static plist that we do; pacman for instance just takes whatever in their equivalent ${STAGEDIR} and calls it a day. Therein lies our problem: there is no reliable way to reliably track bytecode for the purposes of a static plist with the latest Python packaging tooling, not even with wildcards. (We had a fighting chance with the old distutils method, but that's another story.) It is compounded by no stability guarantees within the bytecodes themselves, further cementing that these are little more than instruction caches tailored to each individual installation.

Alternatively, instead of special handling for root, writing bytecode on import can be unconditionally disabled by default. Still does not affect any manual bytecode compilation via compile_py, compileall, et al (apparent in that none of the lang/python ports have changed plists), nor does it affect utilising existing bytecode so long as they match the timestamps and specific Python interpreter they were built against. Most importantly, there is still no divergence from upstream as far as code interpretation and execution is concerned, just less filesystem pollution.

pkg's INSTALL_AS_USER is not a default setting.

There is no difference from upstream as far as actual Python interpretation and execution is concerned. The only difference is no more filesystem-polluting instruction caching when ran as root if such files do not already exist. Manually invoking compile_py, compileall et al are unchanged.

In D38429#875110, @mat wrote:

So what, we have to forbid users running python bits to do anything as root?

It makes sense in that packaged bytecode is going away.

Started an upstream discussion https://github.com/python/cpython/issues/101702 since I'm not sure of any good way to pass the variable globally in the environment for every stage (important for the interactive stage)

Approximating the process as if the Python packaging tooling is the final arbiter, this has to run:

• on Python package install/update
• on Python distribution update
• on deinstall

In D38429#874508, @mat wrote:

From what I understand, you removed sunpoet's fix because of some hypothetical future problem that may never happen.

This problem exists right now, because bytecode is not to be packaged, period. We (and many other operating system-level packagers) have been doing it wrong for years, and only as a crutch due to lack of a trigger mechanism that we now have. D34739 uses trigger support; having bytecode packaged hampers development of that, because proper operation cannot be verified.

use DISTVERSION, bump PORTREVISION, MAINTAINER to python@ as infrastructure

another round of stray paths smh

convert to DISTVERSION, bump PORTREVISION, fix PEP517_BUILD_DEPEND

hopefully no more stray paths

rebase (stray paths)

devel/py-flit-core: switch to DISTVERSION and simplify