Ability to use a local folder to fulfill a dependency

[mosteo]

This PR implements the pinning of dependencies to folders. These folders then act as a wildcard for any version; that is, the dependency will be always satisfied. I chose this approach instead of associating a version to the folder because both opam and cargo work like this, and for crates in progress the version is actually not a concern.

On terminology and internals: for Alire users, both pinning to a version or a folder is presented under the concept of pins (because the idea is to fix a dependency to something concrete). Internally, there are separate concepts, "pin to a version" (already implemented) and "linked to a folder" (new in this PR), and the term softlink/link is used for new types/subprograms that involve these new user pins.

Given the lack of version of these linked crates, internally we don't rely on placeholder releases. Instead, links are represented with a new Alire.Externals.Softlinks type and the solver is aware of them, which has the added benefit of the solver not needing to blindly try releases until finding the good one; instead, links are reused from the solution the solver receives as a basis.

There are two ways of pinning a dependency to a folder: right away at the time of adding the dependency (alr with crate --url path) or later with the pin command (alr pin crate --url path). I named the switch --url instead of --dir because in the foreseeable future we may want to support a remote repository or archive instead (as opam does).

When adding and linking simultaneously, the dependency needs not to exist in the index, which is convenient to rely on unindexed dependencies:
alr with unindexed_crate --url /path/to/working/version

See the new tests for examples of usage. In essence:

$ alr init --bin xxx
$ cd xxx
$ alr with libhello --url ../libhello
Requested changes:                                            

   ✓ libhello * (added)

Changes to dependency solution:

   ⊙ libhello file:/tmp/a/libhello (pinned)

Do you want to proceed?
[Y] Yes  [N] No  (default is Yes) 
Using default: Yes
$ alr with --solve
Dependencies (direct):
   libhello*
Dependencies (external):
   libhello* (direct,linked,target=/tmp/a/libhello)
Dependencies (graph):
   xxx=0.0.0 --> libhello*
┌───────────┐     ┌───────────┐
│ xxx=0.0.0 │ ──> │ libhello* │
└───────────┘     └───────────┘
$ alr setenv
export GPR_PROJECT_PATH="/tmp/a/libhello"
export ALIRE="True"

Goes on top of #437, fixes parts of #240

[Fabien-Chouteau]

So when pinning to a directory, only the GPR_PROJECT_PATH and current directory for actions change. How do you see the URL thing working? One time download or re-download for every alr command?

[Fabien-Chouteau]

Awesome feature by the way :)

[mosteo]

only the GPR_PROJECT_PATH and current directory for actions change

I'm not sure what you mean by actions here... A linked dir won't have actions.

How do you see the URL thing working? One time download or re-download for every alr command?

My current idea is that a remote source archive would be downloaded once, when added. A repository could be pulled for changes via alr update.

[Fabien-Chouteau]

I'm not sure what you mean by actions here... A linked dir won't have actions.

The actions that can be defined in the crate toml:

[[general.actions.'case(os)'.linux]]
type = "post-fetch"
command = ["make"]

My current idea is that a remote source archive would be downloaded once, when added. A repository could be pulled for changes via alr update.

Sounds good 👍

[mosteo]

The actions that can be defined in the crate toml:

A linked folder does not go through fetch or compile steps, so no actions will be run for it. For the root release in the workspace, the compile actions will run normally from its own folder.