unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
* [bug#28531] [PATCH] gnu: Add vcsh.
@ 2017-09-20 19:37 Stefan Reichör
  2017-09-20 20:32 ` bug#28531: " Ludovic Courtès
  0 siblings, 1 reply; 5+ messages in thread
From: Stefan Reichör @ 2017-09-20 19:37 UTC (permalink / raw)
  To: 28531

* gnu/packages/version-control.scm (vcsh): New variable.
---
 gnu/packages/version-control.scm |   36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm
index 235adef..4249073 100644
--- a/gnu/packages/version-control.scm
+++ b/gnu/packages/version-control.scm
@@ -713,6 +713,42 @@ Git repository as normal Git commits, and provides a number of commands to
 manipulate them in various ways.")
     (license license:gpl2)))
 
+(define-public vcsh
+  (package
+    (name "vcsh")
+    (version "1.20151229")
+    (source (origin
+              (method url-fetch)
+              (uri (string-append "https://github.com/RichiH/vcsh/archive/v"
+                                  version ".tar.gz"))
+              (file-name (string-append name "-" version ".tar.gz"))
+              (sha256
+               (base32
+                "1ym3swkh738c3vciffvlr96vqzhwmzkb8ajqzap8f0j9n039a1mf"))))
+    (build-system gnu-build-system)
+    (inputs
+     `(("git" ,git)
+       ("which" ,which)
+       ("perl" ,perl)
+       ("perl-test-harness" ,perl-test-harness)
+       ("perl-shell-command" ,perl-shell-command)
+       ("perl-test-most" ,perl-test-most)))
+    (arguments
+     '(#:phases (modify-phases %standard-phases
+                  (delete 'configure)
+                  (delete 'build))
+       #:make-flags (list (string-append "PREFIX="
+                                         (assoc-ref %outputs "out")))
+       #:test-target "test"))
+    (home-page "https://github.com/RichiH/vcsh")
+    (synopsis "Version Control System for $HOME")
+    (description
+     "Maintain several Git repositories in one single directory.  They all
+maintain their working trees without clobbering each other or interfering
+otherwise.  By default, all Git repositories maintained via vcsh store the
+actual files in $HOME.  But this can be overridden.")
+    (license license:gpl2+)))
+
 (define-public git-test-sequence
   (let ((commit "48e5a2f5a13a5f30452647237e23362b459b9c76"))
     (package

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* bug#28531: [PATCH] gnu: Add vcsh.
  2017-09-20 19:37 [bug#28531] [PATCH] gnu: Add vcsh Stefan Reichör
@ 2017-09-20 20:32 ` Ludovic Courtès
       [not found]   ` <87o9q2o1bw.fsf@xsteve.at>
  0 siblings, 1 reply; 5+ messages in thread
From: Ludovic Courtès @ 2017-09-20 20:32 UTC (permalink / raw)
  To: Stefan Reichör; +Cc: 28531-done

[-- Attachment #1: Type: text/plain, Size: 426 bytes --]

Hi Stefan,

Stefan Reichör <stefan@xsteve.at> skribis:

> * gnu/packages/version-control.scm (vcsh): New variable.

Pushed with the minor changes below (the first sentence of the
description looked awkward to me).

Note that vcsh takes ‘git’ from $PATH.  I wonder if we should keep it
this way, or if we should hard-code the absolute file name to ‘git’ so
that it always works.

Thoughts?

Ludo’.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1633 bytes --]

diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm
index 424907332..78e142b29 100644
--- a/gnu/packages/version-control.scm
+++ b/gnu/packages/version-control.scm
@@ -726,9 +726,10 @@ manipulate them in various ways.")
                (base32
                 "1ym3swkh738c3vciffvlr96vqzhwmzkb8ajqzap8f0j9n039a1mf"))))
     (build-system gnu-build-system)
+    (native-inputs
+     `(("which" ,which)))
     (inputs
      `(("git" ,git)
-       ("which" ,which)
        ("perl" ,perl)
        ("perl-test-harness" ,perl-test-harness)
        ("perl-shell-command" ,perl-shell-command)
@@ -741,12 +742,13 @@ manipulate them in various ways.")
                                          (assoc-ref %outputs "out")))
        #:test-target "test"))
     (home-page "https://github.com/RichiH/vcsh")
-    (synopsis "Version Control System for $HOME")
+    (synopsis "Version control system for @code{$HOME}")
     (description
-     "Maintain several Git repositories in one single directory.  They all
-maintain their working trees without clobbering each other or interfering
-otherwise.  By default, all Git repositories maintained via vcsh store the
-actual files in $HOME.  But this can be overridden.")
+     "vcsh version-controls configuration files in several Git repositories,
+all in one single directory.  They all maintain their working trees without
+clobbering each other or interfering otherwise.  By default, all Git
+repositories maintained via vcsh store the actual files in @code{$HOME},
+though this can be overridden.")
     (license license:gpl2+)))
 
 (define-public git-test-sequence

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* [bug#28531] [PATCH] gnu: Add vcsh.
       [not found]   ` <87o9q2o1bw.fsf@xsteve.at>
@ 2017-09-23 12:52     ` Ludovic Courtès
  2017-09-23 18:10       ` Stefan Reichör
  0 siblings, 1 reply; 5+ messages in thread
From: Ludovic Courtès @ 2017-09-23 12:52 UTC (permalink / raw)
  To: Stefan Reichör; +Cc: 28531

Hello,

Stefan Reichör <stefan@xsteve.at> skribis:

>> Hi Stefan,
>>
>> Stefan Reichör <stefan@xsteve.at> skribis:
>>
>>> * gnu/packages/version-control.scm (vcsh): New variable.
>>
>> Pushed with the minor changes below (the first sentence of the
>> description looked awkward to me).
>>
>> Note that vcsh takes ‘git’ from $PATH.  I wonder if we should keep it
>> this way, or if we should hard-code the absolute file name to ‘git’ so
>> that it always works.
>>
>> Thoughts?
>
> I don't think that it is desirable to change all external tool
> invocations for programs in Guix. I am currently preparing the tool
> atool that has to invoke a lot of archivers.

We always have a choice between “static binding” (where we hard-wire a
tool and its dependencies) and “late binding” (where the dependencies
are searched for at run time.)

Most of the time in Guix we favor static binding: it makes sure that (1)
programs work out of the box, regardless of what happens to be already
installed on your system, and (2) that the program will behave the same
on all systems since its behavior does not depend on external state.

There are exceptions where we want dynamic binding, for instance for
plugins or optional/soft dependencies.

The case of ‘vcsh’ is borderline.  I have a slight preference to
hardwire the dependency on Git (after all, someone might want to use
vcsh without having installed Git before), but I’m open to other
arguments.

Thoughts?

Thanks,
Ludo’.

PS: Please preserve Cc:.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [bug#28531] [PATCH] gnu: Add vcsh.
  2017-09-23 12:52     ` [bug#28531] " Ludovic Courtès
@ 2017-09-23 18:10       ` Stefan Reichör
  2017-09-25  9:50         ` Ludovic Courtès
  0 siblings, 1 reply; 5+ messages in thread
From: Stefan Reichör @ 2017-09-23 18:10 UTC (permalink / raw)
  To: 28531

Hi Ludo,

> Hello,
>
> Stefan Reichör <stefan@xsteve.at> skribis:
>
>>> Hi Stefan,
>>>
>>> Stefan Reichör <stefan@xsteve.at> skribis:
>>>
>>>> * gnu/packages/version-control.scm (vcsh): New variable.
>>>
>>> Pushed with the minor changes below (the first sentence of the
>>> description looked awkward to me).
>>>
>>> Note that vcsh takes ‘git’ from $PATH.  I wonder if we should keep it
>>> this way, or if we should hard-code the absolute file name to ‘git’ so
>>> that it always works.
>>>
>>> Thoughts?
>>
>> I don't think that it is desirable to change all external tool
>> invocations for programs in Guix. I am currently preparing the tool
>> atool that has to invoke a lot of archivers.
>
> We always have a choice between “static binding” (where we hard-wire a
> tool and its dependencies) and “late binding” (where the dependencies
> are searched for at run time.)
>
> Most of the time in Guix we favor static binding: it makes sure that (1)
> programs work out of the box, regardless of what happens to be already
> installed on your system, and (2) that the program will behave the same
> on all systems since its behavior does not depend on external state.
>
> There are exceptions where we want dynamic binding, for instance for
> plugins or optional/soft dependencies.
>
> The case of ‘vcsh’ is borderline.  I have a slight preference to
> hardwire the dependency on Git (after all, someone might want to use
> vcsh without having installed Git before), but I’m open to other
> arguments.
>
> Thoughts?

Thanks for the explaination. I see the benefit of the static binding.
The good thing is that the package versions are reproducable.
However, I am used to the way it works on other systems. There is almost
always the search path used to start other programs.

And to make it even more complicated, I still use Ubuntu and install
some tools using Guix. So it is even possible that I use vcsh from Guix
and git from Ubuntu.

I took a look at the vcsh script. git is hardcoded in many places there.
Patching it to have static binding seems to be complicated. The only
sane solution would be to change the script and make git configurable
and try to make this change upstream. However I am not really keen on
doing this kind of work...

Or do you have another idea how the static binding should be accomplished?

Stefan.

> Thanks,
> Ludo’.
>
> PS: Please preserve Cc:.
o.k. - I interpreted the Cc: "28531-done@debbugs.gnu.org" as flag that
the bug is closed and was unsure what will happen when I respond to the
closed bug...

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [bug#28531] [PATCH] gnu: Add vcsh.
  2017-09-23 18:10       ` Stefan Reichör
@ 2017-09-25  9:50         ` Ludovic Courtès
  0 siblings, 0 replies; 5+ messages in thread
From: Ludovic Courtès @ 2017-09-25  9:50 UTC (permalink / raw)
  To: Stefan Reichör; +Cc: 28531

Hi,

Stefan Reichör <stefan@xsteve.at> skribis:

> Thanks for the explaination. I see the benefit of the static binding.
> The good thing is that the package versions are reproducable.
> However, I am used to the way it works on other systems. There is almost
> always the search path used to start other programs.
>
> And to make it even more complicated, I still use Ubuntu and install
> some tools using Guix. So it is even possible that I use vcsh from Guix
> and git from Ubuntu.

Indeed.  From a reproducibility viewpoint, it’s something we’d like to
avoid, because then vcsh might behave completely differently depending
on what the underlying distro is, and that’s clearly not what we expect
from Guix.

> I took a look at the vcsh script. git is hardcoded in many places there.
> Patching it to have static binding seems to be complicated. The only
> sane solution would be to change the script and make git configurable
> and try to make this change upstream. However I am not really keen on
> doing this kind of work...
>
> Or do you have another idea how the static binding should be accomplished?

I think it might be enough to do a regexp substitution matching all
“git” commands in the script:

  (substitute* "vcsh"
    (("\\<git ([a-z-]+)" _ sub-command)
     (string-append (assoc-ref inputs "git") "/bin/git "
                    sub-command)))

Could you give it a try?

Thanks,
Ludo'.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2017-09-25  9:52 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-20 19:37 [bug#28531] [PATCH] gnu: Add vcsh Stefan Reichör
2017-09-20 20:32 ` bug#28531: " Ludovic Courtès
     [not found]   ` <87o9q2o1bw.fsf@xsteve.at>
2017-09-23 12:52     ` [bug#28531] " Ludovic Courtès
2017-09-23 18:10       ` Stefan Reichör
2017-09-25  9:50         ` Ludovic Courtès

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).