| Message ID | m1leqjcx6q.fsf@fastmail.net |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [bug#57858] gnu: git-annex: Promote git to propagated input | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/comparison | success | View comparision |
| cbaines/git-branch | success | View Git branch |
| cbaines/applying patch | success | View Laminar job |
| cbaines/issue | success | View issue |
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
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
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’.
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
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
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
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 --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))