[RFC] How to make "Alire aware" tools

[Fabien-Chouteau]

Hi @mosteo,

In the context of GNATdoc development, we are thinking about how tools can get information from the Alire manifest, or anything related to Alire context, settings, and so on.

We see several options:

1. Make the Alire library. In theory, the code is structured so that we can make a library, but there's some work required. One drawback will be that the library will be quite heavy with a bunch of dependencies.
2. Create a small Alire manifest parser library. Something simple, based on Ada-TOML only, would be sufficient to get the basic information (name, version, authors, etc.). Of course that means maintaining another mini "parser" for manifests.
3. Use a machine-readable output from alr show:
   a. There would still be a need to "parse" this output and make it available through an API
   b. How do we communicate this to the tool?
   i. alr exec --some-clever-switch write the content to a file and then pass an option to the tool itself to tell where this file is
   ii. Let the tool run alr show itself

I am opening this issue to discuss and get feedback on those options.

[mosteo]

Preliminary thoughts on those points:

1. Indeed most dependencies are in libalire rather than in alr. The split is now clear through alire.gpr and alr.gpr, but indeed the repo contains a single crate. It should be reasonably straightforward to move to a two-crate monorepo.
2. If possible I'd rather avoid having a new separate parser, but having a reusable one would require some work. If a lightweight linkable separate library is indeed wanted, it could involve splitting libalire in two or three smaller bits (types + parser + everything else). Allowable dependencies could be defined here.
3. Having alr --format show --manifest emit/print the manifest in TOML/JSON is no problem; even simpler if dynamic expressions are not desired (i.e., just to get the info that applies to the local environment). That would produce a mostly flat key/value table. Having an API over this starts inching into duplicating functionality in (1) or (2) though.

[godunko]

There is still an issue how to lookup alire.toml file by GNATdoc. May be we can extend Alire to run GNATdoc (like it does for gprbuild) and pass path of the file with extracted information in JSON/XML format?

alire.toml contains name of project file(s) of the crate, I found this way better than adding heuristics to lookup alire.toml to GNATdoc.

[reznikmm]

ALS also uses alr to load the project file. When user doesn't specify the project file but there is alire.toml. ALS runs alr show to fine explicit project file or construct it from the crate name. It also runs alr printenv to get correct environment. Initially I tried to run these two command in parallel, but this caused issues, when one of command fetches dependencies or update alire's cache.