feat: Install plugins directly from Git repositories

[fmotalleb]

This change enhances the plugin installation mechanism by introducing a more flexible Git-based package fetcher.
The new fetch-package-git function (used via the --git flag on the install subcommand) enables fetching a package directly from a Git repository into a temporary directory, with support for additional Git options through environment configuration.

Key details:

• Branch or tag selection: The --branch flag allows checking out a specific branch or tag.
• Shallow clone optimization: Performs a shallow clone using the NUPM_GIT_CLONE_DEPTH env var (default: 1) for faster downloads.
• Custom Git arguments: Supports extra Git options via the NUPM_GIT_CLONE_ARGS environment variable, allowing users to pass flags such as --recurse-submodules or --filter for advanced cloning scenarios.

Effect:

This update removes the need for users to manually clone repositories and install with --path, or for developers to publish modules to a registry. It simplifies plugin/module installation workflows.

Notes:

Additional features such as Git filters, sub-directories, ..., may be added later. For now, the implementation intentionally remains minimal and straightforward.

[kubouch]

I think we can support this, but we already support installation of git packages, see https://github.com/nushell/nupm/blob/main/docs/design/registry.md and the download-pkg command. Your git cloning implementation is better, so I think it should be used also in download-pkg instead of having two separate pieces of code handling git cloning.

Another problem is using mktemp -- this clones into some random directory, but nupm packages are installed into $env.NUPM_HOME. This brings the question where the repository should be cloned, probably $env.NUPM_HOME/modules and we'd assume that the repository contains a Nushell module.

This, however, contradicts the PR description which says that it is meant to support installing plugins. Are you sure you meant plugins, not modules?

[fmotalleb]

Hi @kubouch!

Thanks for the feedback.

About mktemp:
I used it intentionally because this implementation is meant to behave like a shorthand for git clone + install --path.
The temporary directory isn’t used for any permanent storage; it’s just a scratch space for cloning before passing the path to the installer.

• On Linux, mktemp creates directories under /tmp, which are automatically cleaned up on reboot.
• On Windows, it uses the user’s AppData temp directory, which doesn’t clean up automatically but is manageable.

So the cloned data doesn’t persist under $env.NUPM_HOME; it’s ephemeral by design.

Regarding scope; yes, it supports both modules and plugins, since the logic ultimately (kinda) passes the cloned directory to install --path.
So anything that can be installed via --path will work here as well.

As for download-pkg, I agree, my git cloning logic could probably replace or be integrated into that to avoid duplication.
Right now, though, I kept it isolated to keep the initial implementation simple and low-impact.

---

Under the hood, it’s basically doing:

let dir = (mktemp --directory)
git clone $repo $dir
nupm install $dir --path

[kubouch]

Ah, I get it now. Then instead of mktemp we use $env.NUPM_CACHE for cloning repositories. The only difference is that we don't know the version / hash (which is not fully implemented yet), so it would need to always re-clone. Since the logic is almost identical to fetching git packages from the registry, it would be better if the implementation was shared as much as possible.

[fmotalleb]

Updated changes:

• Renamed fetch-package-git to git-clone to better represent its functionality.
• Integrated the git-clone helper into download operations, replacing manual git and checkout steps in download-pkg.
• Replaced mktemp usage with tmp-dir git-clone (git-clone now requires the caller to provide its target dir instead of creating it).

[fmotalleb]

Additionally, note that the new test introduced in this PR fails when there’s no access to GitHub (e.g., in restricted or offline environments).
I wasn’t sure how to make it independent of network access, if offline testing is required.

[kubouch]

OK, seems good, thanks!

I'm not sure why you refactored those throw-errors into asserts, is that for showing the spans? IMO it's slightly less readable now, those flags could have been added to throw-error as well, but not a big deal, we could refactor it later since we need some proper error handling design anyway.