[rollcat]

TBH depending on Python also isn't the best choice - it has become a huge and complex language, goes as far as optionally embedding another full language (Tcl, for Tkinter), all the async stuff, kitchen sink standard library, etc. I don't even know how much effort it would require to bootstrap.

I would personally go with something like Lua - small, trivial to embed, multiple implementations to pick from, etc. It would fit exactly where the shell falls short.

[q66]

it's absolutely the kitchen sink standard library and "complex" language that makes it worth using, because 1) it means no additional dependencies and 2) the language is expressive enough to let the template syntax remain simple and well-abstracted

have you ever tried bootstrapping python? because it's really not a big deal (the only hard dependencies are a C compiler, libffi, and zlib, though distros also add libedit or readline, expat, sqlite, bzip2, xz, and openssl, all trivial dependencies present in more or less any system); tkinter is pretty much always compiled and packaged separately

meanwhile with lua you'd need many additional modules, and the templates would be verbose and far less readable

a non-exhaustive list of stuff python provides that would need to be provided separately:

1) subprocess management 2) path parsing (and normalization, manipulation, etc.) 3) various filesystem operations 4) shell command lexing 5) globs and fnmatch patterns 6) json 7) date/time handling 8) filesystem advisory locks 9) temporary file handling 10) http client (for sources fetching without external subprocess) 11) termios and ptys (for isolation of controlling terminal) 12) regex 13) hashing 14) topological graph sorting 15) cmdline argument parsing 16) readline functionality 17) thread/task pools

and so on and so on

[rollcat]

Don't get me wrong, I love Python, and I've been a user since the 2.4 days. You brought up plenty of good reasons to use it - and my own rule of thumb is to rewrite a shell script in Python once it goes past 100 lines.

My point is that Lua-the-language provides similar expressive power to Python-the-language (including basic stuff like lookup tables), while remaining smaller and simpler to understand than the POSIX shell. It's also simpler to vendor than Python, and you probably want to vendor this kind of stuff to avoid the pain of bootstrapping / circular dependencies.

Now I haven't built a build/packaging system like xbps or apk (few people did), but I've been in charge of devops/releng at work for a decade - and if I learned anything at all, it's that it's better to start with the simplest tool that can do the job, and slowly add what you need. E.g. I wrote a tool in 2016 to replace Ansible in my team, and all of this time it's just been doing its job: <https://github.com/rollcat/judo>. Turned out nobody actually needed the kitchen sink.

[q66]

note: i've been doing lua for two decades and am well familiar with the language itself as well as its inner workings (far less so with python), and i've been building distro tooling for almost as long, and no, definitely not

[rollcat]

I do enjoy Lua, what I miss the most is a more complete and direct interface to POSIX - possibly as a compile-time option, to accommodate the existing embedded use cases.

What would you say is its biggest shortcoming?

[hedora]

Have you ever tried upgrading python on a machine with a large codebase that you need to maintain?

[q66]

sure, in fact i updated an entire distro to a new python major version several times

cbuild started iirc with python 3.8, currently it requires at least 3.12 due to some features (it will stay on that minimum for a while, though newer versions are always supported), updating it has always been seamless though