[sfpotter]

Here's one example of when to commit auto-generated code: if you use a tool like Cython and want to distribute sources to an end user, it is frequently recommended to distribute the C sources generated by Cython instead of the Cython code itself. The given reason is that the end user may not have access to Cython, but will likely have access to a C compiler. (This is frequently the case on scientific clusters where users don't have superuser privileges.)

[daniele_dll]

Importing a C file into a Python session is a practice that can ---easily--- cause ---a lot--- of headaches, the packages required to build the code as python library and make it importable will vary between systems and make it hard to debug in case of crashes. I personally would distribuite the pre-compiled binaries, CI + docker makes that much easier.

The fact that "can be done" doesn't necessarely mean that "it's the right way" to do it.

Going back to embedding auto-generated code, focusing on this specific case, are you telling me that a line in the requirements.txt, on a machine where the user is expected to have access to a compiler, is the reason to keep auto generated code in the repository? Sorry, personally it seems a flaky reason.

Also, the very fact that you mention that users don't have superuser privileges should be even more of a reason to use virtual environments, where you don't need super privileges, or if you can't or want to use virtual environments you can still have multiple paths in the PYTHONPATH env variable and you can install packages in a specific paths leveraging the --target of pip or the PYTHONUSERBASE env variable, solving the issue as well.

I would prefer to suggest my users to improve their runtime environment than enable them to improve the chaos.

[sfpotter]

I don't agree that it's a good practice, I'm simply quoting one example to you since you mentioned you were not aware of any. IIRC, you can find many GitHub issue threads on the Cython repo where they go into more detail. It has been a while since I spent any time thinking about this so the details are no longer fresh.

Unfortunately, suggesting that users improve their runtime environment is frequently a nonstarter for different reasons. (One obvious reason: users either don't have time or technical experience to do so.)