Re: git: f5890bd3cbc6 - main - Revert "Mk/Uses/python.mk: Fix USE_PYTHON=pep517: always compile and install bytecode"
- Reply: Rainer Hurling : "Re: git: f5890bd3cbc6 - main - Revert "Mk/Uses/python.mk: Fix USE_PYTHON=pep517: always compile and install bytecode""
- Reply: Po-Chuan Hsieh : "Re: git: f5890bd3cbc6 - main - Revert "Mk/Uses/python.mk: Fix USE_PYTHON=pep517: always compile and install bytecode""
- In reply to: Po-Chuan Hsieh : "Re: git: f5890bd3cbc6 - main - Revert "Mk/Uses/python.mk: Fix USE_PYTHON=pep517: always compile and install bytecode""
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 07 Feb 2023 18:36:31 UTC
Po-Chuan Hsieh wrote: > Those issues you mentioned might be a problem in the future but clearly > not in the short term. > I'm trying to fix an immediate problem which greatly affects the > development. They are problems now, because they impede any proper fixes. We have been doing quite a few things wrong with Python packaging, and simply fixing "immediate problems" doesn't work. > It may not be good from your point of view but it really fixed the > problem (see below). > If you have a better solution, I'm fine with it. > > > 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. > > > Thanks for pointing out a possible solution but it is still WIP. > It will be *the* solution, because bytecode is not meant to be packaged, but only compiled at install or run-time at user's discretion. The only reason why bytecode was packaged in operating system-level package distributions is how most such systems lack a trigger function that we now have. When Python packaging tooling is the final arbiter, bytecode is compiled only after the installation process completes if the user does not disable it. In our case, pkg(8) is the final arbiter, so such tasking falls to pkg(8)'s triggers and not during stage/packaging. > > The aforementioned build_fs_violations will be investigated. > > > You could reproduce this problem as follows. > 1. Revert d6583d67b69dbf690e6f102e1aec799cb7fd564a (change > devel/py-importlib-metadata back to USE_PYTHON=pep517 which is the > background) > 2. Build a port with USE_PYTHON=pep517. I choose devel/py-pyls-black here. > Now it failed earlier with devel/py-click. > You could expect more ports to be failed/skipped while building hundreds > of ports in my case. > Can't reproduce with a proper PEP-517 bootstrap tooling, which most importantly does not have setuptools in the environment at all. If anything, your build failure only demonstrates just how "problematic, fragile and unreliable" compiling and installing bytecode at stage/package time is. -- Charlie Li …nope, still don't have an exit line.