- Convert ports to use PY_TOMLI to simplify Makefile.
The minimal version is set to 2.0.1 because it is required by multiple ports such as devel/py-poetry.
The upper bound of version is set to 3 because it is limited by devel/py-poetry.
With hat: python
The switch is a collective effort of Wen Heping, Alastair Hogge,
Muhammad Moinur Rahman, Antoine Brodin, Vladimir Druzenko,
Thomas Zander, Daniel Engberg et al.
PR: 275494
Tested by: antoine (multiple exp-runs)
With hat: python
The minimal version is set to 1.1.1 because it is required by devel/py-cattrs.
Convert ports to use PY_EXCEPTIONGROUP to simplify Makefile.
With hat: python
Both our make and gmake use the MAKEFLAGS environment variable but the
values aren't compatible and the latest version of gmake complains about
that. To rule out that any environment variable can cause problems like
this, add a new command SETENVI=/usr/bin/env -i that clears the
environment, and use it to run upstream build systems with a clean
environment.
Introduce a new variable WRK_ENV that contains the environment to use
with SETENVI in all targets that run upstream build commands. Variables
that are common between CONFIGURE_ENV and MAKE_ENV could be moved to
WRK_ENV but for now it just contains a minimal environment:
HOME=${WRKDIR}: Fixes USES=elixir ports that were using the user's HOME.
OSVERSION: For cross building; determines the output of uname -K and
getosreldate(3); affects net/freebsd-telnetd for example.
PATH: Fixes USES=gem ports that were using the user's PATH.
PWD=$${PWD}: Preserve current working directory; affects USES=go ports.
TERM: To preserve colored output to terminals.
TMPDIR: For users who define that.
UNAME_*: For cross building; determines the output of uname(1); affects
lang/python* for example.
This commit deals with everything under Mk/. Ports that have their own
targets running upstream build commands can switch to SETENVI later.
The ports tree adds its definition of ARCH to the MAKEFLAGS environment
variable, which is interpreted by sub-makes as command line arguments,
which means that any definition of ARCH in upstream makefiles was
overridden. The following ports required fixes now that this is no
longer the case.
games/iortcw, games/q3cellshading, games/tremulous:
These use Quake 3 engine code. Fix use of ARCH. Reduce diff between
FreeBSD code and Linux code.
games/legesmotus:
Remove ARCH related patches.
lang/ocaml:
Patch configure script so it detects amd64 correctly. Also make the
powerpc case consistent with the other architectures. This also affects
other ocaml ports like devel/ocaml-ocamlbuild and math/ocaml-num that
include a Makefile.config installed by lang/ocaml. While here, use
SETENVI in check-test target.
net/libnatpmp:
Use of upstream definition of ARCH triggers installation in PREFIX/lib64
on amd64. Disable this.
PR: 276478
Approved by: portmgr (antoine)
Exp-run by: antoine
- Remove unnecessary PYTHON3_DEFAULT
- Replace PYTHON3_DEFAULT with PYTHON_DEFAULT
Regarding DEFAULT_VERSIONS, both python and python3 point to the same value
which makes python3 a duplicate. And we do not really support python=2.7.
Therefore, use python for Python 3.x and python2 for legacy Python 2.7.
- Introduce USE_PYTHON=cryptography{,_build,_test}
- Switch all 96 ports from USES=pycryptography to with USE_PYTHON=cryptography{,_build,_test}
- Remove Mk/Uses/pycryptography.mk
PR: 273727
Approved by: tcberner (portmgr)
Exp-run by: antoine
Suport FindPython.cmake, FindPython3.cmake, FindPython2.cmake modules by
adding Python{,2,3}_EXECUTABLE to CMAKE_ARGS in python.mk.
CMake supports more than one way to search for python. Currently
python.mk passes -DPython_ADDITIONAL_VERSIONS=${PYTHON_VER} to help
FindPython{Interp,Libs}.cmake modules "find" the version of python that
a port build wants to use.
The FindPython{,2,3}.cmake modules don't know anything about
Python_ADDITIONAL_VERSIONS but use Python{,2,3}_EXECUTABLE as the hint.
PR: 262109
Currently "USE_PYTHON=autoplist pep517" generates the PLIST as follows:
- Extract the list of installed files from the RECORD file to the intermediate
PLIST (_PYTHONPKGLIST)
- Manipulate the intermediate PLIST
- Add list of pycache files to the intermediate PLIST
When the RECORD file contains foo.pyc entry, that file will be counted twice in
the PLIST at the end. It will cause check-plist error. This fix removes *.pyc
entries while manipulating the intermediate PLIST to ensure all pycache files
are only counted once.
Should start allowing PEP-517 packages to build and unbreaking
circular dependencies, however short a shelf life, due to gpep517's
almost nonexistant Python dependency tree.
(PyPA build will continue as the preferred build frontend otherwise,
due to official stewardship, but does not preclude a DEFAULT_VERSIONS
hook in the future)
The post-release version is normalized to .postX in PEP440. However, it will be
converted to .pX in FreeBSD which means an older version.
% pkg ver -t 1.2.3 1.2.3.p4
>
If the original release is already in the tree, rather than bumping PORTEPOCH,
you could bump PORTREVISION and add .postX to DISTVERSIONSUFFIX.
This fix allows the port to build in this situation.
The python PEP440 version numbering standard is _mostly_ compatible
with FreeBSD port versioning rules. Exceptions exist, where the
PORTVERSION can be derived from the upstream DISTVERSION
automatically. For example:
PEP440 DISTVERSION: FreeBSD PORTVERSION:
2.3.post1 2.3.p1
Now, this interacts badly with PEP517 build setups. hatchling will
enforce PEP440 complicance, so it isn't practical to modify the ported
code to use exactly the FreeBSD version.
Instead, simply referring to DISTVERSION rather than PORTVERSION will
allow the build process to complete smoothly.
See https://reviews.freebsd.org/D39123 for an example port update
which depends on this change
Approved by: python (maintainer, vishwin)
Differential Revision: https://reviews.freebsd.org/D39124
This reverts commit c17ddfbf66.
This causes breakage on several ports, and the next iteration
requires a full exp-run. See:
Differential Revision: https://reviews.freebsd.org/D34739
data_files was not initially supported in the framework under the
guise that PyPA through setuptools deprecated the practice. However,
other build backends like flit still support (and advertise as a
"newer" feature) data_files, and certain packages continue to install
operating system-specific files like man pages using Python's
packaging system.
This expands RECORD parsing to account for any data_files beyond
entry_points installed to bin/. It is limited to certain directories
in hier(7) listed under /usr/local to prevent wheels from installing
files to arbitrary locations.
Tested by: yasu (first pass)
Differential Revision: https://reviews.freebsd.org/D38050
Facilitates compiling, writing and removing bytecode files (.pyc)
in site-packages after all pkg transactions have been completed.
Technical details: https://wiki.freebsd.org/Python/CompiledPackages
Fixes reports of Python port builds as root failing on filesystem
violations due to bytecode file writes where the port did not include
them in the package.
For those ports/packages that currently package bytecode, some
checksum mismatches on those files may occur. This is harmless and
will be rectified, in large as part of a USE_PYTHON=distutils
overhaul to reduce churn.
While here, implement a long-standing todo item of letting lang/python
ports use python.mk bits. Not only does this obviate duplicate
variables in each Makefile, but SUB_LIST (also added) is used for
these triggers.
Co-authored by: tcberner
Approved by: tcberner (mentor)
Differential Revision: https://reviews.freebsd.org/D34739
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,
removed, or changed between versions of Python," thus "should not
be considered to work across Python VMs or Python releases." [2]
This is important to ensuring correctness for those ports specifying
NO_ARCH.
Instead of compiling and installing bytecode at stage/package time,
there is a WIP, review D34739, that compiles and installs bytecode
at install time instead, using triggers.
The aforementioned build_fs_violations will be investigated.
This reverts commit de6965254c.
With hat: python
Approved by: tcberner (mentor, portmgr)
Reference: https://wiki.freebsd.org/Python/PEP-517 [0]
https://packaging.python.org/en/latest/specifications/binary-distribution-format/ [1]
https://docs.python.org/3/library/dis.html [2]
- 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]
The living binary distribution format specification derived from
PEP-427 [0] prescribes that:
In distribution names, any run of -_. characters (HYPHEN-MINUS,
LOW LINE and FULL STOP) should be replaced with _ (LOW LINE), and
uppercase characters should be replaced with corresponding lowercase
ones. This is equivalent to PEP 503 normalisation followed by
replacing - with _. Tools consuming wheels must be prepared to
accept . (FULL STOP) and uppercase letters, however, as these
were allowed by an earlier version of this specification.
This fixes staging for packages built under PEP-517 with dashes
(HYPHEN-MINUS) in their names.
[0] https://packaging.python.org/en/latest/specifications/binary-distribution-format/
Reported by: amdmi3
Tested by: yasu, rhurlin
PR: 268893
With hat: python
Approved by: mentors (implicit)
USE_PYTHON=pep517 takes no arguments. Operation is similar to
USE_PYTHON=distutils, although the build backend specified in
pyproject.toml is to be specified in BUILD_DEPENDS explicitly. A
usage guide and implementation primer is available at:
https://wiki.freebsd.org/Python/PEP-517
With hat: python
Approved by: fluffy (mentor)
Co-authored by: yuri
PR: 255722
Differential Revision: https://reviews.freebsd.org/D36290
Change proposal was in discussion with open questions and additional
documented design requirement [0] for submitter to review and provide
feedback on, which was not provided.
Submitter (and anyone else) is welcome to work with python@ to
produce an appropriately reviewed feature.
[0] https://wiki.freebsd.org/Python/PEP-517
With hat: python (vishwin, koobs)
PR: 255722, 265660, 265692, 265693
Approved by: fluffy (mentor)
