Re: [PATCH] project-test extensible

[Ship Mints]

I like the idea of "project tasks" and I'm not really sure what the name "multi" is supposed to suggest. project-task seems closer to what this is trying to support.

I took a quick look at the patch and at your project-multi-mode package. The biggest thing that stood out to me is that all settings are global, when I think they should be project specific. If I were to use project tasks, I'd configure them as I configure eglot for each project subtree: using dir locals. I do have a default global eglot configuration for various languages but that's a convenience and not something I'd want to rely on as part of a generally self-contained project and one that gets shared among team members, all of whom have different personal Emacs configurations.

Many projects are multi-language and monorepos for larger projects tend to have quite varying content and tooling requirements including some that conflict with one another. A server component team uses different linting/formatting rules and stricter tests than a front-end component team which tends to be higher velocity. For project-task to be effective for more complex projects, it would have to support dir locals, right?

On Sun, Jan 19, 2025 at 7:53 PM Ergus <spacibba@aol.com> wrote:

Hi:

Please find attached a proposed patch to add the command project-tests
to project.el. Documentation is still missing and Dmitry may remember we
were talking about this a while ago. But I bring it back again.

The main idea is to give a customization variable for the user and a
cl-generic for backend developers in order to modify/specify the
project-compile command and (the new added) project-test one. But also
allow to extend for more commands in the future with very little code.

The idea is that any external project.el backend could "construct"
complex build and test commands with the extra information if should
hold. But also, if the user wants to specify them as dir-local he could
do it very easily as well.

The actual patch does not modifies the current behavior, but will allow
to extend project.el externally (for example, to support different build
systems)

See an example: https://github.com/Ergus/project-multi-mode

That's a simple backend that uses this new "api" to offer a transparent
experience for compile backends in less than 400 lines (including
documentation and header).

Best,
Ergus