Please remove cogapp

[thoughtsunificator]

Why should cogapp be installed prior to building? Isn't it deps management parts of the building process?

[plp13]

Hi @thoughtsunificator.

It's used for parsing the config file. Originally, I had all my config options in a bunch of structures. But C doesn't have advanced OOP or introspection features, and thus there was no way to have a clean and DRY solution that parses the file just by looking into those structs. So, every time I added a new config option, I also had to add code to a myriad of functions that would handle it.

cogapp, together with a bit of Python scripting, helped me avoid this. To add a new option, all I have to do now is add a line to config_def.py. In most cases, anyway.

So, it's essential, unless you'd like to rewrite Qman from scratch and/or in a different language. Also, I don't think installing cogapp is too much trouble. It's just a build dependency, and Python is available everywhere these days.

[thoughtsunificator]

This does not answer why user have to manage qman dependencies.

[plp13]

Dependencies are a problem for the packager, not the app developer.

For end-users who do not want to build Qman themselves, packages for some operating systems do exist, one of which (for Arch Linux) is maintained by myself. We've got a list here:

https://github.com/plp13/qman/blob/main/doc/PACKAGES.md

[thoughtsunificator]

Software dependencies are SOFTWARE dependencies problems. Again, why should users manage every single software dependencies?

…

On Thu, Jan 29, 2026 at 07:04:52AM -0800, Pantelis Panayiotou wrote: plp13 left a comment (plp13/qman#81) Dependencies are a problem for the packager, not the app developer. For end-users who do not want to build Qman themselves, packages for some operating systems do exist, one of which (for Arch Linux) is maintained by myself. We've got a list here: https://github.com/plp13/qman/blob/main/doc/PACKAGES.md -- Reply to this email directly or view it on GitHub: #81 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

-- Cordialement, Romain LEBESLE.

[plp13]

I can't modify Qman's build scripts to install third-party apps on people's computers... Maybe there's something you're trying to tell me that I don't understand?

[thoughtsunificator]

You do not have to install anything on anyone's computer, the deps should be managed locally, that means at the root of where the application is located and not system-wide.

…

On Thu, Jan 29, 2026 at 07:35:13AM -0800, Pantelis Panayiotou wrote: plp13 left a comment (plp13/qman#81) I can't modify Qman's build scripts to install third-party apps on people's computers... Maybe there's something you're trying to tell me that I don't understand? -- Reply to this email directly or view it on GitHub: #81 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

-- Cordialement, Romain LEBESLE.

[plp13]

I still don't understand. Are you proposing one of the following?

1. Have meson.build create a Python virtual environment and install cogapp in it locally?

• Not a good idea, IMHO. Too much unnecessary complexity.

2. Include a cogapp in Qman's source tree?

• Terrible idea. Even more complexity, and cogapp is a separate project we'll have to keep up with.

3. Pre-build config.h and config.c and distribute them with the source?

• Maybe. We're doing this already with the man page, which requires pandoc, a fussy bit of software that requires an entire Huskell stack to be installed.

So...?

[thoughtsunificator]

So it's a good idea to lock in a specific version of cogapp system-wide knowing that many software will require x version of that particular module. Plus the fact that the module is depending on a specific version of Python which itself is depending on a specific set of native libraries. Also pipx is authored by pip pop aka pypa itself, might be worth looking into.

…

On Thu, Jan 29, 2026 at 08:22:09AM -0800, Pantelis Panayiotou wrote: plp13 left a comment (plp13/qman#81) I still don't understand. Are you proposing one of the following? 1. Have `meson.build` create a Python virtual environment and install `cogapp` in it locally? - Not a good idea, IMHO. Too much unnecessary complexity. 2. Include a `cogapp` in Qman's source tree? - Terrible idea. Even more complexity, and `cogapp` is a separate project we'll have to keep up with. 3. Pre-build `config.h` and `config.c` and distribute them with the source? - Maybe. We're doing this already with the man page, which requires `pandoc`, a fussy bit of software that requires an entire Huskell stack to be installed. So...? -- Reply to this email directly or view it on GitHub: #81 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

-- Cordialement, Romain LEBESLE.

[thoughtsunificator]

Yet another solution: https://packaging.python.org/en/latest/specifications/inline-script-metadata/

[plp13]

Yet another solution: https://packaging.python.org/en/latest/specifications/inline-script-metadata/

I don't see how a specification for embedding metadata in single-file Python scripts would help. We don't have such scripts in the Qman repo. config_def.py is not a script. It's a Python module that is included by cogapp's input files (as can be seen here and here).

That said, your idea of not having cogapp as a dependency has merit. We can do it with a script, like we did to remove the pandoc dependency for the manual page.

Reopening.

[thoughtsunificator]

Since meson does not consider all dependencies as dependencies for some reasons no one will ever know, i'd reckon we can wrap cog_cmd around a shell script just like you suggested (I believe?) and then in the shell script we check:

• That python exists and is the exact version we need
• That python-pipx exists and is the exact version we need
• We run cogman via pipx using:
  pipx run --spec git+https://github.com/nedbat/cog@badd4c31d77dec54f745c03ae673e753df47163d cogapp $@

That commit checksum points to ~3.6.0 I believe.

[plp13]

No, the script will only be run by the core developers (me, essentially). It will just assume that cogapp is installed, and will run it to generate config.h and config.c. These two files will then be part of the repo. Thus, there won't be a cogapp dependency for end-users who want to compile from source.