Skip to content
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

Support plugin install giturl#gitref #1201

Open
airtonix opened this issue Apr 10, 2022 · 3 comments · May be fixed by #1204
Open

Support plugin install giturl#gitref #1201

airtonix opened this issue Apr 10, 2022 · 3 comments · May be fixed by #1204

Comments

@airtonix
Copy link

Is your feature request related to a problem? Please describe

i'm always frustrated with i have to fill these things out.

lets support installing asdf plugins from a git repo with a gitref (tag, branch, commit)

Describe the proposed solution

asdf plugin install https://github.com/heliumbrain/asdf-just#6cc5790

Describe similar asdf features and why they are not sufficient

  1. cajole broken plugin author into fixing their code
  2. get stonewalled there
  3. fork the broken plugin repo
  4. fix the code
  5. remove old broken plugin
  6. point at different repo

lets say the author fixes their code, but then later on decides to change things...

the only way i can guard the onboarding process of my team is to fork every asdf plugin and use those repos instead.

Describe other workarounds you've considered

crying.

vic added a commit to vic/asdf that referenced this issue Apr 15, 2022
Previously it was only possible to clone plugin repos on their default branch.
This pull-request allows the `plugin-add` command to take an aditional
argument for specifying a git-ref used for `git clone`.

Note: The `plugin-update` command already was able to take a `git-ref`,
but this feature eliminates the need of doing `plugin-add` and immediatly
`plugin-update` just for setting the git-ref to use.

Sometimes it's convenient to specify another plugin-repo branch or release-tag,
instead of using the repos' default branch.

For example, if a plugin becomes unstable on its default branch because
a bug was introduced, or if the fix is only available at an experimental
branch, people might want to try those changes.

Also, some advanced plugins, like
[asdf-direnv](https://github.com/asdf-community/asdf-direnv) can have
tagged releases or `develop` branches that can potentially be
more *experimental* but more feature-forward than the `master` branch.

Added a test that exercises clonning using an specific branch name.

Documented on help.txt and had keep all other commands help aligned.

Closes asdf-vm#1201
@vic vic linked a pull request Apr 15, 2022 that will close this issue
vic added a commit to vic/asdf that referenced this issue Apr 15, 2022
Previously it was only possible to clone plugin repos on their default branch.
This pull-request allows the `plugin-add` command to take an aditional
argument for specifying a git-ref used for `git clone`.

Note: The `plugin-update` command already was able to take a `git-ref`,
but this feature eliminates the need of doing `plugin-add` and immediatly
`plugin-update` just for setting the git-ref to use.

Sometimes it's convenient to specify another plugin-repo branch or release-tag,
instead of using the repos' default branch.

For example, if a plugin becomes unstable on its default branch because
a bug was introduced, or if the fix is only available at an experimental
branch, people might want to try those changes.

Also, some advanced plugins, like
[asdf-direnv](https://github.com/asdf-community/asdf-direnv) can have
tagged releases or `develop` branches that can potentially be
more *experimental* but more feature-forward than the `master` branch.

Added a test that exercises clonning using an specific branch name.

Documented on help.txt and had keep all other commands help aligned.

Closes asdf-vm#1201
vic added a commit to vic/asdf that referenced this issue Apr 15, 2022
Previously it was only possible to clone plugin repos on their default branch.
This pull-request allows the `plugin-add` command to take an aditional
argument for specifying a git-ref used for `git clone`.

Note: The `plugin-update` command already was able to take a `git-ref`,
but this feature eliminates the need of doing `plugin-add` and immediatly
`plugin-update` just for setting the git-ref to use.

Sometimes it's convenient to specify another plugin-repo branch or release-tag,
instead of using the repos' default branch.

For example, if a plugin becomes unstable on its default branch because
a bug was introduced, or if the fix is only available at an experimental
branch, people might want to try those changes.

Also, some advanced plugins, like
[asdf-direnv](https://github.com/asdf-community/asdf-direnv) can have
tagged releases or `develop` branches that can potentially be
more *experimental* but more feature-forward than the `master` branch.

Added a test that exercises clonning using an specific branch name.

Documented on help.txt and had keep all other commands help aligned.

Closes asdf-vm#1201
@jthegedus
Copy link
Contributor

For reference, plugins do support updating to a specific branch or git tag:

From asdf help:

asdf plugin update <name> [<git-ref>]   Update a plugin to latest commit on
                                        default branch or a particular git-ref

Used as:

asdf plugin add firebase https://github.com/jthegedus/asdf-firebase
# update to specific tag
asdf plugin update firebase v1.1.0
# or with a sha
asdf plugin update firebase 57f29ec

#1204 will obviously make this easier and require a single step

@ChadRehmKineticData
Copy link

What is the current status of this issue? Is there a consideration for adding gitref support?

@hyperupcall
Copy link
Contributor

hyperupcall commented Aug 23, 2023

Hi @ChadRehmKineticData, this is a community run project. Maintainers of this project are volunteers and work in their spare time to contribute.

If you want to increase the priority of the issue, feel free to upvote the original post so the maintainers can properly gauge interest.

There doesn't seem to be anyone voicing negative support for this feature, so I'd say that if a PR adds support, It'll likely get added. Unfortunately, there is a backlog of PRs and it doesn't seem like they are being resolved anytime soon. So there is consideration, but it is up for someone themselves to add support, which may take a while to eventually merge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants