Skip to content

Detect and use Alire metadata found in pinned directory#450

Merged
mosteo merged 3 commits into
alire-project:masterfrom
mosteo:feat/dir-deps
Jun 19, 2020
Merged

Detect and use Alire metadata found in pinned directory#450
mosteo merged 3 commits into
alire-project:masterfrom
mosteo:feat/dir-deps

Conversation

@mosteo
Copy link
Copy Markdown
Member

@mosteo mosteo commented Jun 16, 2020

Goes on top of #449.

PR #447 introduces the ability to pin a folder that needs not be an Alire crate. This allows the use of Ada code entirely out of the Alire ecosystem to fulfill a dependency. The shortcoming is that any dependencies introduced by such code will remain unknown and have to be manually dealt with. Also, if the target folder was, indeed, an Alire crate, its information is ignored.

This is an incremental feature in which, if the target folder contains Alire metadata, it is loaded and used to

  • Verify the crate we are pinning matches its dependency in name
  • Add its dependencies during resolution
  • Add its project paths during building
  • Optionally, autodetect the crate for a shorthand alr with --url form.

In short, the pinned Alire crate is used normally as if it had been retrieved as a regular dependency, except for the version, which is ignored (the dependency will always be fulfilled, as if it were a "raw" pinned folder).

@mosteo mosteo marked this pull request as ready for review June 16, 2020 11:50
@mosteo mosteo force-pushed the feat/dir-deps branch 4 times, most recently from 2dce4c8 to 9824fac Compare June 18, 2020 17:21
@mosteo mosteo requested a review from Fabien-Chouteau June 18, 2020 17:42
Comment thread doc/user-changes.md Outdated
affect the user experience. It is intended as a one-stop point for users to
stay on top of `alr` new features.

## Use crate metadata when pinning to a directory
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome I was about to suggest that when reading the main PR :)

@Fabien-Chouteau
Copy link
Copy Markdown
Member

* Add its dependencies during resolution

If there are more than one release in the crate, which one is going to be used for that?

@mosteo
Copy link
Copy Markdown
Member Author

mosteo commented Jun 19, 2020

If there are more than one release in the crate, which one is going to be used for that?

This should cause an error, because we expect the local alire/crate.toml to contain only the checked out release metadata. When you alr get a release that's what's stored. For a never-published crate, init also only creates one release.

Actually this ties in a bit with a follow-up discussion I want to have about the maintenance/publishing workflow, because I think we should move to making alire/crate.toml manually edited only and put under version control. I'm organizing my ideas and will open an issue soon before doing anything.

mosteo added 3 commits June 19, 2020 20:26
If a path given to with/pin --use contains a loadable alire workspace (i.e.,
for a crate manually initialized, or retrieved with `get`), the release found
there will be used to retrieve additional dependencies, and its project paths
will also be used.
When adding a dependency as a pinned dir, and the target dir is a regular Alire
crate, we can autodetect the crate we are adding as dependency. In that case
the command becomes `alr with --use <path>`. This can also be useful in the
future for remote URLs that will also provide the crate being retrieved.
@mosteo mosteo merged commit 0db9ca8 into alire-project:master Jun 19, 2020
@mosteo mosteo deleted the feat/dir-deps branch June 19, 2020 19:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants