I think we should only commit with according additions to CHANGES and the porter's handbook, to avoid astonishment.

LGTM, but other than the relocation; I see no difference. Tested with

In D34739#895778, @vishwin wrote:

In D34739#895772, @bapt wrote:

As far as I know from the time when I participated to the events about reproducible build the issues has been fixed, at least instead of claiming it is not deterministic, can you state what makes it non deterministic?

It's still not, never has and probably never will. While PEP-552 adds an alternative to mtime comparisons (a computed hash), the use of a magic number that can vary between environments (in addition to interpreter versions) already makes it non-deterministic. Further, PEP-552 acknowledges other facets of non-determinism, particularly inconsistent marshalling of set objects (such an implementation is necessary by default for security reasons).

Increased file sizes in the upcoming CPython 3.12 is also concerning.

I also wonder why we don't install a 3.7+ compatible Python script and call that from the lua trigger. It would be far more useful (as in count of available developers) to write this in Python and not Lua, and we'd get proper debugging and logging libs for free. Lua is a bit minimalistic for the rather complex task at hand.

As a more general comment, I removed some immature code. I am not too troubled about *how* we solve it, but we need robust code that properly traps errors, properly reports them, and is fully tested, and DOES NOT GET COMMITTED BEFORE it's properly tested and approved by all. Python isn't your average leaf port sandbox in the playground, but high-profile stuff. And we surely should not comment anything in the next few days (hours) before 2023Q2 has branched. If something is mature and does not break semantics of other ports, we can still MFH to quarterly later, or just really clean up for 2023Q3 before July.

In D34739#895719, @vishwin wrote:

In D34739#895706, @bapt wrote:

To be honnest I am not convinced we should pursue in that direction, only debian seems to be doing something like that and they use a python script to compile and cleanup called by a trigger. All other OSes I have checked are not at all doing anything in that direction.

Because nearly nobody else has a trigger functionality like we do.

In D39261#893754, @matthew wrote:

I believe there was a recent, possibly contraversial, change to generate .pyc files dynamically at pkg install time using a pkg script, rather than including those in the main package. This apparently parallels the way python wheels work, and has a number of advantages.

One side effect has been that all of the pycache directories now show up as "checksum mismatch" in the daily security e-mails.

In D39004#888511, @vishwin wrote:

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}.

Don't even think about un-flavouring everything, near future consumers need to use this with all supported Python.

@vishwin please fix this up and after that also D34739, before working on any new stuff.

@jbeich wrote to the mailing lists:

this isn't working properly. Reopening