LocalRegistry.jl icon indicating copy to clipboard operation
LocalRegistry.jl copied to clipboard

Use jll version of git via Git package.

Open GunnarFarneback opened this issue 3 years ago • 9 comments

This PR removes the prerequisite to have a working git installed in your PATH and instead employs the Git package to use a bundled git from the git_jll package.

~However, the Git package requires a minimum Julia version of 1.6, which I don't want to impose on LocalRegistry just yet.~ There are some workarounds possible, but for now, to try this out, do (in Pkg mode):

pkg> add LocalRegistry#git_jll

This also adds an ~~external_git~~ custom_git keyword argument, so by using custom_git = "git" you can opt out of the bundled git and use your external one.

~~Update:` Back on hold awaiting a solution to https://github.com/JuliaVersionControl/Git.jl/issues/50.~~ Resolved.

Update March 2024: This is now implemented as a package extension. Mostly this means that you need to do

using LocalRegistry, Git

if you want to use the bundled git.

GunnarFarneback avatar Jun 02 '21 07:06 GunnarFarneback

Welcome to Codecov :tada:

Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.

Thanks for integrating Codecov - We've got you covered :open_umbrella:

codecov-commenter avatar Jun 02 '21 07:06 codecov-commenter

Possibly helpful here, Julia 1.7's changelog includes the following:

  • It is now possible to use an external git executable instead of the default libgit2 library for the downloads that happen via the Git protocol by setting the environment variable JULIA_PKG_USE_CLI_GIT=true.

https://github.com/JuliaLang/julia/blob/v1.7.0-rc2/NEWS.md#package-manager

While it wouldn't resolve a situation where a legitimate git client isn't installed, this might help with ssh authentication issues

caleb-allen avatar Oct 25 '21 21:10 caleb-allen

That's not really relevant here. LocalRegistry has never used libgit2 but relied on an external git executable being available. The point of this PR is to effectively bundle an external git.

GunnarFarneback avatar Oct 26 '21 18:10 GunnarFarneback

The MacOS build failures are discussed in https://github.com/JuliaVersionControl/Git.jl/issues/40#issuecomment-951223459.

GunnarFarneback avatar Oct 27 '21 07:10 GunnarFarneback

https://github.com/JuliaVersionControl/Git.jl/issues/50 looks resolved now. Wondering if there are any updates planned on this PR? Thanks!

3f6a avatar Mar 10 '24 12:03 3f6a

Yes, the Git package problems have been resolved. Now it's mostly a question of deciding whether to add it as an unconditional dependency, a package extension, or if there's some third option.

The drawback of the first option is that you always have to install the Git package and the git_jll artifact, which in many CI scenarios is a waste of bandwidth and time. The main advantages are that the user instructions can be simplified, that there's no need to cater for old git versions, and that someone who doesn't already have an external git does not need to install it.

Implementing a package extension solves the drawback of the first option and keeps most of the advantages, except that now the user instructions become more complicated again, and you need to explain about installing the Git package and the differences between using Localregistry and using LocalRegistry, Git.

What may be nicer is to use the Git package if it happens to be installed and otherwise look for an external git, but I'm not sure if that can be done in a sane way.

GunnarFarneback avatar Mar 10 '24 17:03 GunnarFarneback

I'd vote for the second option. using LocalRegistry, Git is not that complicated. Moreover we can move from this to the first option later on if desired, without it being a breaking change.

Out of curiosity, who uses LocalRegistry on CI? I would've thought it's package mostly used locally, on a user's machine.

3f6a avatar Mar 10 '24 17:03 3f6a

I do, for one. At work all Julia packages have a CI job which runs only on merge to master, and calls LocalRegistry to register a new version. If the version number wasn't bumped, nothing happens, and if it was it's automatically registered.

It's a good point that a package extension is a strict improvement over the current state, apart from additional instructions. A future change from a package extension to an unconditional dependency would still be a breaking change, but introducing a package extension isn't.

GunnarFarneback avatar Mar 10 '24 17:03 GunnarFarneback

A drawback of a package extension is that it requires Julia 1.9 or later. However, I have implemented a way to make it possible to use the Git package also with older Julia versions.

GunnarFarneback avatar Mar 16 '24 19:03 GunnarFarneback