On Wed, Apr 17, 2024 at 05:12:07PM -0500, Maxwell G wrote: > On 4/13/24 06:41, Fabio Valentini wrote: > > On Sat, Apr 13, 2024 at 1:18 PM Zbigniew Jędrzejewski-Szmek > > <zbyszek@xxxxxxxxx> wrote: > > > Yes. But actually I think Rust is the optimal choice here. Writing > > > this in Python would be possibly slightly nicer, but we don't want > > > to pull the interpreter and packages into the buildroot. Python > > > also has the problem (challenge?) that it needs to be bootstrapped > > > once per year. The less packages are involved in the bootstrap, the > > > easier it is. And if the brp was written in Python, we'd need to > > > deal with that, and it would probably increase the number of builds > > > which are done without the cleanup. Having this as an indepedent > > > binary avoids some of the issues with bootstrap. > > I think Rust*would* be a good choice here ... > > BUT add-determinism uses pyo3 to link to CPython, so it pulls in > > python3-libs anyway. > > So you get the downsides of pulling in Python without the upsides of > > using Rust ... > > Would it be possible to shell out to Python instead of using pyo3? I assume > add-determinism's Python handler is not that complicated given that > marshalparser does most of the work. Possible — yes. Desirable — not clear. Firstly, Python interpreter startup with module imports is relatively slow. In the current implementation we do that just once in each worker, and then read the list of files to process from a socket. People were worried about the postprocessing being slow, so I implemented a fairly nice multiprocessing scheme that cuts down on this avoidable overhead. Secondly, calling a library function is generally preferred over calling a binary for the purposes of error handling. For example, right now I can catch an exception and handle it as appropriate. When calling a subprogram, we only get an error code and maybe some error message, and, for example, supressing or customizing the message for some classes of exceptions cannot be done cleanly. Thirdly, bootstrapping might actually be easier with a link to a library. We might install older python3-libs together with a new versions of python3-libs and python3, since they don't conflict, but we can have only one /usr/bin/python… But yeah, just calling an external python binary is certainly an option if the current approach doesn't work out. Thank you for the suggestion. Zbyszek -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
