-
-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Detect and use Alire metadata found in pinned directory #450
Conversation
2dce4c8
to
9824fac
Compare
doc/user-changes.md
Outdated
@@ -4,6 +4,19 @@ This document is a development diary summarizing changes in `alr` that notably | |||
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 |
There was a problem hiding this comment.
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 :)
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 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 |
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.
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
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).