git-credential-netrc.perl is not built and is not available in `exec-path`

[Subject: [Bug] git-credential-netrc.perl is not built and is not available in exec-path]

which is located in contrib/credential/netrc.

I'm missing some basic information:
- what platform are you running on?

- what commands did you use to install Git?

- what are you trying to do? That can help us with understanding the problem or giving better advice tailored to the use case. The netrc credential helper is mostly meant as a demo, since libcurl supports ~/.netrc on its own already.

which is located in contrib/credential/netrc.

If I'm not mistaken, it's because it sets the SCRIPT_PERL environment variable here:
https://github.com/git/git/blob/88dd4282d949cdafff516650c1be8aaf4d67983f/contrib/credential/netrc/Makefile#L13

But the Git Makefile un-sets environment variables here:
https://github.com/git/git/blob/88dd4282d949cdafff516650c1be8aaf4d67983f/Makefile#L587

Also credential helpers in contrib/credential are not present in the output of git help -a, is that a bug?

Quoted 9 lines · Siavash

which is located in contrib/credential/netrc.

If I'm not mistaken, it's because it sets the SCRIPT_PERL environment variable here:
https://github.com/git/git/blob/88dd4282d949cdafff516650c1be8aaf4d67983f/contrib/credential/netrc/Makefile#L13

But the Git Makefile un-sets environment variables here:
https://github.com/git/git/blob/88dd4282d949cdafff516650c1be8aaf4d67983f/Makefile#L587

Quoted 2 lines

Also credential helpers in contrib/credential are not present in the output of git help -a, is that a bug?

Things in contrib are not built by default because they don't necessarily work everywhere. For example, the osxkeychain credential helper won't compile on Linux because the requisite shared libraries are specific to macOS. You'll need to compile them manually and install them in a suitable location.

Note that that location can be someplace like ~/bin, if that's in your PATH. For example, since the Debian packages don't yet ship the libsecret credential helper, I've built it and placed it there. Now that I've done that, git help -a shows git credential-libsecret as an option.

Quoted 5 lines · brian m. carlson

Things in contrib are not built by default because they don't necessarily work everywhere. For example, the osxkeychain credential helper won't compile on Linux because the requisite shared libraries are specific to macOS. You'll need to compile them manually and install them in a suitable location.

I agree with this, but just following up with a bit of a devil's
advocate: why not put osxkeychain into a regular "make install", but make it conditional via a Makefile knob, like we do for other platform-specific features?

And yet, my impression is that basically every Git user on macOS is using it every day, because both Apple Git and homebrew build it by default (and I think at least in the case of Apple Git, it's hard-coded into the config). A little scary, but nobody seems to have complained. :)

I wonder if we could build it and run it through t0303 as part of the mac CI process (though I recall at the time that it was really finicky for automated testing; it wouldn't even run over an ssh session).

Likewise, we probably could be building and testing the libsecret ones via the Linux CI job (I don't use those either myself, but presumably they pass t0303).

Quoted 4 lines

I agree with this, but just following up with a bit of a devil's
advocate: why not put osxkeychain into a regular "make install", but make it conditional via a Makefile knob, like we do for other platform-specific features?

Sure, let's do it.

For osxkeychain, it's probably pretty simple to always build it, since macOS will always have the appropriate libraries if the compiler is installed.

I would be in favor of also building by default on Linux and having a Makefile knob to disable that, since the requisite libraries are a part of nearly every distribution and doing so will spur distros to ship it, which many do not.

I suspect that just opening a bug report against distro packages might get some traction (especially if it comes with a patch to create the extra package).

I do wonder if packagers are hesitant to reach into contrib/,

[1] I was actually surprised I had libsecret installed at all. Apparently pinentry-gtk2 links against it, which I have for use with gpg. But my system might not be considered typical anyway, as I don't use any kind of "desktop environment".

Quoted 3 lines · Jeff King

I suspect that just opening a bug report against distro packages might get some traction (especially if it comes with a patch to create the extra package).

I have tried that; do doesn't work. If git developers have $x in "contrib" it's for a reason.

Quoted 2 lines

I do wonder if packagers are hesitant to reach into contrib/,

Of course they are! The word "contrib" has an obvious meaning.

This is precisely the reason why I tried to graduate "contrib/completion" out of "contrib" to no avail:
https://lore.kernel.org/git/[email protected]/

Quoted 6 lines · Felipe Contreras

Quoted 3 lines · Jeff King

I suspect that just opening a bug report against distro packages might get some traction (especially if it comes with a patch to create the extra package).

Quoted 7 lines

I have tried that; do doesn't work. If git developers have $x in "contrib" it's for a reason.

Quoted 2 lines

I do wonder if packagers are hesitant to reach into contrib/,

Of course they are! The word "contrib" has an obvious meaning.

[Minor edit to the quoted text to inline the link]:

Quoted 3 lines

This is precisely the reason why I tried to graduate "contrib/completion" out of "contrib" to no avail:
https://lore.kernel.org/git/[email protected]/

Seems like that patch just got no replies at the time. FWIW I'd very much be for it and would encourage you to re-submit it.

I'm not sure s/shared/contrib/g is the best naming though, but maybe I'm contributing to needless bikeshedding by mentioning that.

You apparently named it like that to match where distros usually install it (/usr/share), but we also have docs there, locale, and the perl/ directory usually (well, at least on my distro) ends up there.

I wonder if just a top-level completion/* wouldn't be best, or if we want to group them all together something like optional/{completion,credential}/ or other name suggesting that these are meant to interact with not-always-present 3rd party software. Maybe integrations/* ?

For some of these names a general re-arrangement of contrib/* would be a logical thing to follow, e.g. I think it would make sense to carve out various ci/, contrib/coccinelle, Documentation/doc-diff, check-builtins.sh etc. and other "only for supporting git.git development" or "only called by our own Makefile(s)" into some consistently named pattern.

I'm also very much in favor of building and testing all of this software by default, to the best of our ability. We've had some avoidable bitrot e.g. in subtree and mw-to-git in the past, some of that is a pain to test (e.g. requiring an installed MediaWiki), but we can usually build/test some part of it (e.g. in that case, does it even compile as Perl code?). In other cases we could compile/test things by default on certain platforms if they're platform-specific.

Quoted 23 lines · Ævar Arnfjörð Bjarmason

Quoted 6 lines · Felipe Contreras

Quoted 3 lines · Jeff King

I suspect that just opening a bug report against distro packages might get some traction (especially if it comes with a patch to create the extra package).

Quoted 7 lines

I have tried that; do doesn't work. If git developers have $x in "contrib" it's for a reason.

Quoted 2 lines

I do wonder if packagers are hesitant to reach into contrib/,

Of course they are! The word "contrib" has an obvious meaning.

[Minor edit to the quoted text to inline the link]:

Quoted 3 lines

This is precisely the reason why I tried to graduate "contrib/completion" out of "contrib" to no avail:
https://lore.kernel.org/git/[email protected]/

Quoted 5 lines

Seems like that patch just got no replies at the time. FWIW I'd very much be for it and would encourage you to re-submit it.

I'm not sure s/shared/contrib/g is the best naming though, but maybe I'm contributing to needless bikeshedding by mentioning that.

It is the best location because that's where completions go.

You can check the location bash-completion suggests to install completions to:

  % pkg-config --variable=completionsdir bash-completion
  /usr/share/bash-completion/completions

In the case of zsh it's /usr/share/zsh/site-functions.

Additionally, if you install them in your home directory, it should be $XDG_DATA_HOME/bash-completion/completions.

$XDG_DATA_HOME is $HOME/.local/share (analogous to /usr/share).

Quoted 3 lines

You apparently named it like that to match where distros usually install it (/usr/share), but we also have docs there, locale, and the perl/ directory usually (well, at least on my distro) ends up there.

Distributions install them there, because that's where they are expected (by bash-completion and zsh).

Quoted 5 lines

I wonder if just a top-level completion/* wouldn't be best, or if we want to group them all together something like optional/{completion,credential}/ or other name suggesting that these are meant to interact with not-always-present 3rd party software. Maybe integrations/* ?

extra/ is a better name.

However, there's already many things that are optional, like gitk and git-gui, do they belong there too? For that matter locales are optional too.

I think if such a decison to have an extra/ directory is made, it should be orthogonal to the completion graduation.

Quoted 6 lines

For some of these names a general re-arrangement of contrib/* would be a logical thing to follow, e.g. I think it would make sense to carve out various ci/, contrib/coccinelle, Documentation/doc-diff, check-builtins.sh etc. and other "only for supporting git.git development" or "only called by our own Makefile(s)" into some consistently named pattern.

Me too.

Quoted 7 lines

I'm also very much in favor of building and testing all of this software by default, to the best of our ability. We've had some avoidable bitrot e.g. in subtree and mw-to-git in the past, some of that is a pain to test (e.g. requiring an installed MediaWiki), but we can usually build/test some part of it (e.g. in that case, does it even compile as Perl code?). In other cases we could compile/test things by default on certain platforms if they're platform-specific.

Yeah, some spring cleaning would be good.

I'll put sending the patch in my unending to-do list.

Quoted 15 lines · Felipe Contreras

Quoted 2 lines · Ævar Arnfjörð Bjarmason

I'm not sure s/shared/contrib/g is the best naming though, but maybe I'm contributing to needless bikeshedding by mentioning that.

It is the best location because that's where completions go.

You can check the location bash-completion suggests to install completions to:

  % pkg-config --variable=completionsdir bash-completion
  /usr/share/bash-completion/completions

In the case of zsh it's /usr/share/zsh/site-functions.

Quoted 4 lines

Additionally, if you install them in your home directory, it should be $XDG_DATA_HOME/bash-completion/completions.

$XDG_DATA_HOME is $HOME/.local/share (analogous to /usr/share).

*Nod* I mean just because it ends up there in the FHS doesn't mean it's
best for us to mirror that structure in git.git.

Quoted 13 lines

Quoted 3 lines

You apparently named it like that to match where distros usually install it (/usr/share), but we also have docs there, locale, and the perl/ directory usually (well, at least on my distro) ends up there.

Distributions install them there, because that's where they are expected (by bash-completion and zsh).

Quoted 5 lines

I wonder if just a top-level completion/* wouldn't be best, or if we want to group them all together something like optional/{completion,credential}/ or other name suggesting that these are meant to interact with not-always-present 3rd party software. Maybe integrations/* ?

Quoted 8 lines

extra/ is a better name.

However, there's already many things that are optional, like gitk and git-gui, do they belong there too? For that matter locales are optional too.

I think if such a decison to have an extra/ directory is made, it should be orthogonal to the completion graduation.

The line I was attempting to draw was components that optionally interact with optional 3rd party software.

The i18n framework isn't like that because we build it and interact with ourselves, ditto for say PCRE. Optional, but /usr/bin/git is using it.

As opposed to bash/zsh completions, git will run just fine without either of those shells installed.

The git-gui and gitk programs are also first-party software, just like git-send-email or whatever. We just have knobs not to build them because of the dependencies. It looks like we might be spinning them away from git.git entirely in slow-motion, but so far they're first-class commands.

I wonder if just a top-level completion/* wouldn't be best, or if we want to group them all together something like optional/{completion,credential}/ or other name suggesting that these are meant to interact with not-always-present 3rd party software. Maybe integrations/* ?

I think dispelling the conception by distro people must begin with an update to contrib/README where it clearly says these are "contributed software" that are not part of "Git". They are not something we stand behind like what we have in the rest of the source tree.

Right now the Arch Linux's git package does this:

find contrib/ -name '.gitignore' -delete
cp -a ./contrib/* "$pkgdir"/usr/share/git/

Also, the description there is rather stale. For example, the last paragraph must go as its entirety. The ecosystem has expanded thousand-fold since the document was written, and we no longer encourage people to add new things to contrib/ directory at all. We instead encourage them to write and sell their ware on their own merit alone, without planning to "borrow" authority and gain undue advantage over its competitors by being in the contrib/ area in our tree.
.

Quoted 6 lines · Junio C Hamano

I think dispelling the conception by distro people must begin with an update to contrib/README where it clearly says these are "contributed software" that are not part of "Git". They are not something we stand behind like what we have in the rest of the source tree.

Archlinux packagers did remove contrib/ because they don't interest on it [1]:

Quoted 5 lines

Right now the Arch Linux's git package does this:

find contrib/ -name '.gitignore' -delete
cp -a ./contrib/* "$pkgdir"/usr/share/git/

Quoted 10 lines

Also, the description there is rather stale. For example, the last paragraph must go as its entirety. The ecosystem has expanded thousand-fold since the document was written, and we no longer encourage people to add new things to contrib/ directory at all. We instead encourage them to write and sell their ware on their own merit alone, without planning to "borrow" authority and gain undue advantage over its competitors by being in the contrib/ area in our tree.
.

So basically we should deprecate contrib/, and then after next few releases we proceed to remove it, right?

Quoted 5 lines · Ævar Arnfjörð Bjarmason

I wonder if just a top-level completion/* wouldn't be best, or if we want to group them all together something like optional/{completion,credential}/ or other name suggesting that these are meant to interact with not-always-present 3rd party software. Maybe integrations/* ?

Add-ons?

I think dispelling the conception by distro people must begin with an update to contrib/README where it clearly says these are "contributed software" that are not part of "Git". They are not something we stand behind like what we have in the rest of the source tree.

We instead encourage them to write and sell their ware on their own merit alone, without planning to "borrow" authority and gain undue advantage over its competitors by being in the contrib/ area in our tree.

If I'm not mistaken, it's because it sets the SCRIPT_PERL environment variable here:
https://github.com/git/git/blob/88dd4282d949cdafff516650c1be8aaf4d67983f/contrib/credential/netrc/Makefile#L13

But the Git Makefile un-sets environment variables here:
https://github.com/git/git/blob/88dd4282d949cdafff516650c1be8aaf4d67983f/Makefile#L587