installed files are in different locations in the dist-info directory
(names are normalized, and licenses move to a subdirectory), so PLISTs
generated on older versions won't package on newer versions and vice-versa
setuptools opportunistically picks up extensions and builds can fail if
dpb junking occurs during build (only really likely on a slower building
port with compiled code rather than a pure Python port). it doesn't
happen _all_ that often (I've gone months without seeing it in my i386
bulk builds) but isn't that easy to identify from the logs and people
that can run more jobs in parallel hit it more frequently, so let's go
back to nojunk and see how we go.
(use case: setuptools-rust has some fiddly setup so if you use that, it needs
to be in MODPY_PYBUILD, if the port also need setuptools_scm you would then
need to list in bdep, and we don't really want the warning in that situation).
getting added to _sysconfigdata, which results in some compiled Python
extensions picking it up.
noticed while investigating surprising memory use in LLVM 18+ while
compiling cython-generated C code (~700MB in LLVM 16/17; 10GB+ in 18).
llvm #124749
common mistakes (in particular, missing changes to build system done with an
update).
not fatal because sometimes there may be a reason for it not matching up,
but it's not resulting in many false warnings.
defer printing this until fake-install where it's more likely to be seen
(otherwise it's likely to be hidden by a wall of scrolling messages with
some build systems).
(since any python branch switch touches thousands of ports):
- stop using FLAVOR=python3 / MODPY_FLAVOR / etc in py3 ports.
- rename MODPY_EGG_VERSION (which refers to an obsolete packaging
format) with MODPY_DISTV (easier to type and line up in Makefiles)
bumps and adjustments to follow. lots of help from tb@, thanks!
has been set to <empty> on py3 ports since Feb 2021, since when there
has been enough churn that existing PLIST entries etc referencing it
are not trustworthy. no change to python-module(5) needed as it wasn't
documented there anyway.
When MODPY_TEST_LINK_SO is enabled, python.port.mk links all .so files
in ${WRKSRC} which is required when port using tests which use Python
code that loads .so files via relative imports.
tweeks, feedback and OK: kn@ sthen@
on sparc64 - I tested aarch64) with a few tweaks to allow updating stable.
merge meta/python3 into lang/python/3, there's no need for the separate
empty package any more now that we only have one 3.x version (pkg_add
python%3 will work).
tb's version was OK kmos@
Compared to the various ad-hoc ones used in the ports tree, this sets
parallelism if MAKE_JOBS is set, strips ${WRKINST} from the pyc files
(i.e. the pobj directory), and uses standard optimization levels.
(I have diffs for the various ports using ad-hoc compileall.py that
I'll test)
adding to the standard pytest command line. Can be used for e.g. -v (to add
verbosity), --color=yes, adjust traceback print mode, etc. See "py.test -h".
layout alongside the switch to using python 3.11 by default - multiple 3.x
versions haven't been useful enough to be worth the extreme pain to keep
@conflict markers correct now that we have -stable packages to deal with).
looks reasonable to tb@
sthen