diff mbox series

[bug#57858] gnu: git-annex: Promote git to propagated input

Message ID m1leqjcx6q.fsf@fastmail.net
State New
Headers
Series [bug#57858] gnu: git-annex: Promote git to propagated input |

Commit Message

Konrad Hinsen Sept. 16, 2022, 12:37 p.m. UTC 
* gnu/packages/haskell-apps.scm (git-annex): changed inputs
[propagated-inputs]: Add git
[inputs]: Remove git
---
 gnu/packages/haskell-apps.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Comments

Maxime Devos Sept. 16, 2022, 3:02 p.m. UTC | #1 
On 16-09-2022 14:37, Konrad Hinsen wrote:
> * gnu/packages/haskell-apps.scm (git-annex): changed inputs
> [propagated-inputs]: Add git
> [inputs]: Remove git
> ---
>   gnu/packages/haskell-apps.scm | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)

What's the reason for this patch?  My guess is that it's because 
git-annex cannot find git:

$ guix shell --pure git-annex -- git-annex test
git-annex: git: createProcess: posix_spawnp: does not exist (No such 
file or directory)

If so, propagation (which as a few small downsides) can be avoided with 
an appropriate substitute* fixing the file name of the git binary.

Greetings,
Maxime
Konrad Hinsen Sept. 17, 2022, 9:56 a.m. UTC | #2 
Maxime Devos <maximedevos@telenet.be> writes:

> What's the reason for this patch?  My guess is that it's because 
> git-annex cannot find git:

That was indeed the starting point. But...

> If so, propagation (which as a few small downsides) can be avoided with 
> an appropriate substitute* fixing the file name of the git binary.

... I tried that and still got error messages whose exact cause I don't
quite understand.

What made me opt for git as a propagated input is that (1) it works just
fine and (2) there isn't much you can do with git-annex without having
git as well. git is even the official user interface of git-annex.

Cheers,
  Konrad
Ludovic Courtès Oct. 17, 2022, 8:07 a.m. UTC | #3 
Hi,

Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:

> Maxime Devos <maximedevos@telenet.be> writes:
>
>> What's the reason for this patch?  My guess is that it's because 
>> git-annex cannot find git:
>
> That was indeed the starting point. But...
>
>> If so, propagation (which as a few small downsides) can be avoided with 
>> an appropriate substitute* fixing the file name of the git binary.
>
> ... I tried that and still got error messages whose exact cause I don't
> quite understand.
>
> What made me opt for git as a propagated input is that (1) it works just
> fine and (2) there isn't much you can do with git-annex without having
> git as well. git is even the official user interface of git-annex.

Yeah, that sounds reasonable: I’d have made the same suggestion as
Maxime but any improvement here is welcome.

Applied, thanks!

Ludo’.
Simon Tournier Oct. 17, 2022, 9:29 a.m. UTC | #4 
Hi,

On lun., 17 oct. 2022 at 10:07, Ludovic Courtès <ludo@gnu.org> wrote:

>> What made me opt for git as a propagated input is that (1) it works just
>> fine and (2) there isn't much you can do with git-annex without having
>> git as well. git is even the official user interface of git-annex.
>
> Yeah, that sounds reasonable: I’d have made the same suggestion as
> Maxime but any improvement here is welcome.

We are usually not propagating.  For example, emacs-magit or git-lfs or
etc.

From my understanding, this change is not coherent with other parts.

About (2), what do you mean Konrad?  Is ’git-annex’ not working as
expected?  Well, ’git annex’ is a shorthand for ’git-annex’ and I
thought this ’git-annex’ is self-contained; for which operations
’git-annex’ depends on the ’git’ binaires?

Cheers,
simon
Konrad Hinsen Oct. 17, 2022, 10:11 a.m. UTC | #5 
zimoun <zimon.toutoune@gmail.com> writes:

> About (2), what do you mean Konrad?  Is ’git-annex’ not working as
> expected?  Well, ’git annex’ is a shorthand for ’git-annex’ and I
> thought this ’git-annex’ is self-contained; for which operations
> ’git-annex’ depends on the ’git’ binaires?

Maxime quoted a simple command line example. git-annex requires git for
pretty much everything it does.

But that's not the question here. As Maxime said, git could just be a
standard (non-propagated) input with a small patch to git-annex. That
makes it work to a large degree (requiring you to replace "git annex" by
"git-annex" in all command lines), but it occasionally failed for me and
I didn't invest much effort to explore why, given that I consider it
pointless to try to use git-annex without git.

But you are right in pointing out that this is an instance of a
situation for which Guix should have a general policy. git-lfs is
probably in exactly the same situation. Not emacs-magit though: it works
perfectly fine without exposing git in the same profile. Being a git
plugin is not the same as being a git wrapper.

Cheers,
  Konrad
Simon Tournier Oct. 17, 2022, 11:02 a.m. UTC | #6 
Hi Konrad,

On lun., 17 oct. 2022 at 12:11, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:

> But you are right in pointing out that this is an instance of a
> situation for which Guix should have a general policy. git-lfs is
> probably in exactly the same situation. Not emacs-magit though: it works
> perfectly fine without exposing git in the same profile. Being a git
> plugin is not the same as being a git wrapper.

From my understanding, the general policy is to not propagate git. :-)

From gnu/packages/version-control.scm, where xyz: is the line number

--8<---------------cut here---------------start------------->8---
778:(define-public git-cal                     no inputs
907:(define-public git-crypt                   inputs: git
960:(define-public git-remote-gcrypt           no inputs
1108:(define-public python-git-multimail       inputs: git
1311:(define-public git-flow                   inputs: no git
1451:(define-public git-test-sequence          no inputs
2681:(define-public git-annex-remote-rclone    inputs: no git
2901:(define-public git-when-merged            inputs: git
2952:(define-public git-imerge                 inputs: git
2997:(define-public git-lfs                    native-inputs only and no git
3046:(define-public git-open                   inputs: no git
3392:(define-public git-filter-repo            inputs: no git
--8<---------------cut here---------------end--------------->8---

The package git-repo from (gnu packages android) contains git as
inputs.  The package git-absord from (gnu packages rust-apps) does not
contains git as inputs.


I understand the issue but I think the propagation is not the correct
solution. :-)


Cheers,
simon
Maxime Devos Oct. 17, 2022, 12:55 p.m. UTC | #7 
On 17-10-2022 12:11, Konrad Hinsen wrote:
> But you are right in pointing out that this is an instance of a
> situation for which Guix should have a general policy. git-lfs is
> probably in exactly the same situation. Not emacs-magit though: it works
> perfectly fine without exposing git in the same profile. Being a git
> plugin is not the same as being a git wrapper.

The current policy, IMO, is that plugins don't propagate what they are 
plugged into -- even if the plugin is useless without the thing it 
plugs-in into (compare: search paths are set in 'consumers', not 
'producers').

Taking 'emacs-magit' as an example, emacs-magit is an Emacs plugin, but 
it doesn't propagate emacs.

Likewise, (in some usages) 'git-annex' is a git plugin, yet it (IMO) 
shouldn't propagate git.

Greetings
Maxime.
diff mbox series

Patch

diff --git a/gnu/packages/haskell-apps.scm b/gnu/packages/haskell-apps.scm
index 50380281d7..d5e855cf9a 100644
--- a/gnu/packages/haskell-apps.scm
+++ b/gnu/packages/haskell-apps.scm
@@ -462,8 +462,9 @@  (define-public git-annex
            ghc-utf8-string
            ghc-uuid
            ghc-vector
-           git
            rsync))
+    (propagated-inputs
+     (list git))
     (native-inputs
      (list ghc-tasty ghc-tasty-hunit ghc-tasty-quickcheck ghc-tasty-rerun
            perl))