Re: [PATCH] project-test extensible

[Ergus]

Hi Ships:

On Mon, Jan 20, 2025 at 03:03:59PM -0500, Ship Mints wrote:
> 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.

The name project-multi is because it adds support for multiple project
types (cmake, meson, automake, etc).

project-multi is a personal tool, and I showed it as a POC on how the
proposed api function could be used, I don't even share it in elpa o
melpa.

> 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.

None of the settings are global at all. Actually the patch to project.el
was made explicitly to allow project specific, directory-local,
connection-local or even buffer-local values throw a single variable:
`project-extra-info'.

The only global variable in project-multi is project-multi--alist (which
is an internal var, not a custom), and it is actually a "cache"" to
emulate the "project-local" behavior you mention. This alist has the
project root as a key and the associated value is a plist of
project-specific information. This is similar to how connection-local
variables work internally, but for projects.

In fact, I use project-multi daily with 3 simultaneos projects, one of
them in a remote host.

The code in project-multi is eplicitly designed to manage multiple and
remote project efficiently (avoid redundant root searches in the
storage, memoize values by host and project-roots, avoid redundant calls
to find-executable or locate-dominating-file).

But also to respect directory-local or connection-local variables if
they are set.

> If I were to use project tasks, I'd configure them as I configure eglot
> for each project subtree: using dir locals.

You can do that in project.el with the given patch, and that's what I
actually do :)

Set the `project-extra-info' variable to:
(setq project-extra-info
    '(:compile-command "command" :test-command "other command"))

You can do it in a connection-local:

(connection-local-set-profile-variables
        'my/host-profile
        '(project-extra-info . (:compile-command "command" :test-command "other 
command")))
(connection-local-set-profiles '(:application tramp :host "yourhost") 
'my/host-profile)

Or directory-local in .dir-locals.el

(project-extra-info . (:compile-command "command" :test-command "other 
command"))

Or buffer-local in the file footer comment

As the docstring in the patch explains, the variable takes precedence
over any backend defined function.

> 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?

project-multi has no customs, so, not sure what you plan to configure in
dir-locals.

The current project.el has difficulties working with multiple
roots. However, project-multi goes around that issue and supports
multiple backends/roots for a given file.

In project-multi I define the project (what returns project-current) as
a plist: That plist actually contains project-specific values like
:name, :root, :backend, and there is an :others entry to list other
backends in the same root.

For example, one project could have a cmake backend, but usually has
git, in this case cmake will be the :backend but git will be one of the
:others. When cmake does not bring information for a project-command,
then project-multi attempts to use the other backends (for example a
cmake backend does not give information about all the files for
project-files, but git does)

Best,
Ergus
> 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