[RFC] `alr install` mark II

[mosteo]

A rough prototype for alr install based on the discussion in #1048, using a "hidden" workspace to ensure the installed prefix is consistent (only one version of everything, all using the same compiler, etc).

Things that can be tested:

1. alr install hello (and other crates, as long as they build properly)
2. alr install (shows what's installed)
3. alr install --del hello

Then, to see how this could help to install binary crates I've prepared a gnatstudio release repackaging the regular one with an additional project file that only contains Artifacts. You can test that with:

1. alr index --name mosteo --add git+https://github.com/mosteo/alire-index
2. alr install gnatstudio

Then you need to add $HOME/.config/alire/prefix/bin to your path.

Currently, a crate not containing a project file won't be installed, and that's why I've prepared this wrapped gnatstudio. Conceivably we could have a fallback that simply copies the binary release tree into the prefix using a mock project file (in order to simplify uninstallation). That would allow using gnatstudio releases as-is.

There are many things missing: printing the environment needed to use the prefix, a way to run things inside that environment a la alr exec, hardening against build failures, passing build profiles and variables... But before any of that I wanted to get some feedback.

[onox]

If a user is in the folder of a crate, how does the user install the crate? Apparently it's not alr install.

Then you need to add $HOME/.config/alire/prefix/bin to your path.

$HOME/.config is meant for configuration files, so I don't think it is the right place for binaries and shared files. Why not use $HOME/.local or $HOME/.alire or use some environment vars?

[mosteo]

If a user is in the folder of a crate, how does the user install the crate? Apparently it's not alr install.

That's currently not doable as it's not trivial right now. It's one of many improvements that would come later on, see below.

There's however the alr install --standalone option that makes a gprinstallation of your workspace (to a private location, defaults to ${CRATE_ROOT}/prefix. This kind of installation is not intended for addition/removal of crates later on; instead it's as a way to generate a final standard prefix for e.g. distribution to 3rd parties.

But I understand what you are more interested is the first variety of install where you can manipulate the user-wide default prefix, and add your crate to it. Definitely not losing sight of it.

With this prototype I'm for now more interested in testing the idea of maintaining installation consistency with minimal intervention in the current codebase. There are many improvements that could be made later on without changing the interface or the user perception of what's going on:

• Doing incremental installation/removal (now is from scratch every time).
• Using the already installed dependencies during incremental installation.
• Installing user crates together with indexed crates.
• ...

$HOME/.config is meant for configuration files, so I don't think it is the right place for binaries and shared files. Why not use $HOME/.local or $HOME/.alire or use some environment vars?

Right you are. .alire seems the obvious choice for a default here. (You can select prefixes already with alr install --prefix=...)

Thanks for the feedback!

[Fabien-Chouteau]

@mosteo sorry it took me so long to look at this.

There are many things missing: printing the environment needed to use the prefix, a way to run things inside that environment a la alr exec

Do we need that? Isn't it just a PATH to set?

passing build profiles and variables

Why is there something special needed here?

[mosteo]

@mosteo sorry it took me so long to look at this.

No prob!

Do we need that? Isn't it just a PATH to set?

Actually yes. Anything else would be for mere convenience.

passing build profiles and variables Why is there something special needed here?

As there's no manifest in which to set variables, if any crate required them it wouldn't be possible. Admittedly a corner case and not prioritary.

Still, this PR is a bit raw. I'm currently experimenting with a few improvements to avoid reinstalls and if that pans out as expected that would be a good first candidate for merging.

[Fabien-Chouteau]

Do we need that? Isn't it just a PATH to set?

Actually yes. Anything else would be for mere convenience.

I worried that it will bring confusion with existing printenv and exec commands.

passing build profiles and variables Why is there something special needed here?

As there's no manifest in which to set variables, if any crate required them it wouldn't be possible. Admittedly a corner case and not prioritary.

I think we still have to work on the perimeter of this feature. For instance have definition of what it means for a crate to be "install-able":

• Is a bin crate
• Doesn't have crate config vars without default value
• Etc.

Still, this PR is a bit raw. I'm currently experimenting with a few improvements to avoid reinstalls and if that pans out as expected that would be a good first candidate for merging.

I don't know how cargo is handling it but I think it's possible to have different executables that depend on the same library but with different versions.

[mosteo]

I think we still have to work on the perimeter of this feature. For instance have definition of what it means for a crate to be "install-able":

Yes, we want to have good documentation on this. And preferably enforce these things so crates that don't comply are detected instead of failing in mysterious ways. I will add a text document so these things don't get lost.

• Is a bin crate

In this regard: if we want to rely on gprinstall for everything, binary crates should also contain a project file with Install package and Artifacts.

• Doesn't have crate config vars without default value
• Etc.

I don't know how cargo is handling it but I think it's possible to have different executables that depend on the same library but with different versions.

From my reading, everything is linked statically. Dynamic libraries in rust seem to be not that widespread. Unfortunately I can't locate now where I read this in relation to cargo install.

I wonder if forcing libraries to generate differently named static files (e.g. libblah.1.0.0.a would be enough to be able to install different versions without conflict. I don't see why not but since nobody does this I don't know...

[mosteo]

I don't know how cargo is handling it but I think it's possible to have different executables that depend on the same library but with different versions.

Thinking a bit more about it, we might be able to do something like nix does and have all libraries compiled in their own place. But I'm not sure this would work with gprinstall, or if we would need LD_LIBRARY_PATH, or what would happen on Windows... and if soft links are out of picture (for Windows's sake), that also reduces options. I need to do more experimenting.

[mosteo]

This is not going to go in as-is so I'm closing it. We'll go piecemeal as discussed, starting with just binary crates.