NOTE: If this package has multiple flavors (see below), then use one of them instead of the name specified above. NOTE: This is a Python port. Instead of py311-glcontext listed in the above command, you can pick from the names under the Packages section.
python.mk: rename PYTHON_EXT_SUFFIX to PYTHON_TAG, document, etc
EXT_SUFFIX, according to PEP 3149, refers to the full tag and
extension for compiled extension module objects, eg .cpython-311.so,
.cpython-313t.so, etc. We do not use the correct semantic meaning,
and this usage becomes ambiguous and confusing when tags do not
match between bytecode and compiled extension module objects.
Rename our PYTHON_EXT_SUFFIX to PYTHON_TAG to align with PEP 3147's
specification of a magic tag, which consists of implementation name
and shorthand version only. This is meant for bytecode and other
files containing this tag in their filename that do not depend on
a specific Python ABI for the same version. Chase all existing
consumers.
(Only the first 15 lines of the commit message are shown above )
Revert "Mk/Uses/python.mk: Fix USE_PYTHON=pep517: always compile and install
bytecode"
Despite installer's default behaviour to compile and install bytecode,
we are not doing so going forward at stage/package time. [0] During
initial development and qualification of PEP-517 framework support,
compiling and installing bytecode at stage/package time was considered,
but was found problematic, fragile and ultimately unreliable, both
currently and historically (with USE_PYTHON=distutils), due to our
fixed plist requirement. While the living binary distribution format
(wheel) specification [1] says to compile bytecode, that is in the
pure Python package management context (pip, etc); nuance always
exists when interacting with "system" package management.
Additionally, "bytecode is an implementation detail of the CPython
interpreter. No guarantees are made that bytecode will not be added,
(Only the first 15 lines of the commit message are shown above )
Mk/Uses/python.mk: Fix USE_PYTHON=pep517: always compile and install bytecode
- While I'm here, use long options for easier reading [1][2]
- Bump PORTREVISION of dependent ports (USE_PYTHON=pep517) for package change
It fixes build_fs_violation of dependent ports in poudriere (with -t flag).
It is also the default behavior of installer [2].
from py-sphinx log:
=>> Checking for staging violations... done
=>> Error: Filesystem touched during stage (files must install to ${STAGEDIR}):
extra: usr/local/lib/python3.9/site-packages/importlib_metadata/__pycache__
=>> Cleaning up wrkdir
from installer documentation:
--compile-bytecode
Possible choices: 0, 1, 2
generate bytecode for the specified optimization level(s) (default=0, 1)
--no-compile-bytecode
don’t generate bytecode for installed modules
Default: False
With hat: python
Reference: https://pypa-build.readthedocs.io/en/stable/ [1]
https://installer.pypa.io/en/stable/cli/installer/ [2]
