User Details
- User Since
- Jan 26 2018, 10:31 AM (269 w, 2 d)
Today
Yesterday
Wed, Mar 22
% 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.
Thu, Mar 16
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).
Wed, Mar 15
Mon, Mar 13
Sun, Mar 12
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
Sat, Mar 11
Thu, Mar 9
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
Tue, Feb 28
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
Mon, Feb 27
For those who've lived under a rock, I'm not under mentorship.
Sun, Feb 26
only allow select directories under hier(7)
Sat, Feb 25
lang/cjs: pull in commit from cjs to fix clang-15 build
Feb 22 2023
Feb 18 2023
Feb 15 2023
- silence bytecode compile/delete messages, except for errors
- add CHANGES and UPDATING entries for SUB_LIST and trigger
Feb 14 2023
use more SUB_LIST entries on triggers
Feb 12 2023
Obviated in favour of D34739
Feb 11 2023
Obviated in favour of D34739
individualise between the different interpreters/distributions
Feb 10 2023
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.
Feb 9 2023
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.
It makes sense in that packaged bytecode is going away.
Feb 8 2023
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
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.
Feb 7 2023
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