[PATCH] Add yaggo.

[PATCH] Add yaggo.

[Ben Woodcroft]

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

Actually, I lie, this patch only sort of works. The issue is that it 
only works when a ruby package is also installed, GEM_PATH does not get 
set as part of the ruby-build-system for yaggo. The lib/ files are 
copied to what I gather is the correct place, but the env isn't right.

The same also appears to be true of other ruby packages e.g. ruby-hoe:
$ guix package -i ruby-hoe
..
ben@u:~/git/guix$ guix package --search-paths
warning: failed to install locale: Invalid argument
export PATH="/home/ben/.guix-profile/bin:/home/ben/.guix-profile/sbin"
export PYTHONPATH="/home/ben/.guix-profile/lib/python3.4/site-packages"
export 
PKG_CONFIG_PATH="/home/ben/.guix-profile/lib/pkgconfig:/home/ben/.guix-profile/share/pkgconfig"
export GUILE_LOAD_PATH="/home/ben/.guix-profile/share/guile/site/2.0"
export 
GUILE_LOAD_COMPILED_PATH="/home/ben/.guix-profile/share/guile/site/2.0"
export CPATH="/home/ben/.guix-profile/include"
export LIBRARY_PATH="/home/ben/.guix-profile/lib"
export ACLOCAL_PATH="/home/ben/.guix-profile/share/aclocal"

i.e. no GEM_PATH entry, hence:
$ sow -h
/gnu/store/9iifw37m8vd5bkj0fh67ndc5f2da46wb-ruby-2.2.2/lib/ruby/2.2.0/rubygems/dependency.rb:315:in 
`to_specs': Could not find 'hoe' (>= 0) among 9 total gem(s) 
(Gem::LoadError)
Checked in 
'GEM_PATH=/home/ben/.gem/ruby/2.2.0:/gnu/store/9iifw37m8vd5bkj0fh67ndc5f2da46wb-ruby-2.2.2/lib/ruby/gems/2.2.0', 
execute `gem env` for more information
     from 
/gnu/store/9iifw37m8vd5bkj0fh67ndc5f2da46wb-ruby-2.2.2/lib/ruby/2.2.0/rubygems/dependency.rb:324:in 
`to_spec'
     from 
/gnu/store/9iifw37m8vd5bkj0fh67ndc5f2da46wb-ruby-2.2.2/lib/ruby/2.2.0/rubygems/core_ext/kernel_gem.rb:64:in 
`gem'
     from /home/ben/.guix-profile/bin/sow:22:in `<main>'

Files are there though:
$ ls /home/ben/.guix-profile/lib/ruby/gems/2.2.0/gems/
hoe-3.13.1  yaggo-1.5.4

FYI: I actually only care about yaggo because it is a build dependency 
of jellyfish, but I'm having some problems with make check so no patch yet.

Thanks,
ben

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-gnu-Add-yaggo.patch --]
[-- Type: text/x-patch; name="0001-gnu-Add-yaggo.patch", Size: 2159 bytes --]

From d220bdeac89660108de96a96107daf89182310e0 Mon Sep 17 00:00:00 2001
From: Ben Woodcroft <donttrustben@gmail.com>
Date: Wed, 24 Jun 2015 14:32:26 +1000
Subject: [PATCH] gnu: Add yaggo.

* gnu/packages/ruby.scm (yaggo): New variable.
---
 gnu/packages/ruby.scm | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/gnu/packages/ruby.scm b/gnu/packages/ruby.scm
index af87cf5..19006d3 100644
--- a/gnu/packages/ruby.scm
+++ b/gnu/packages/ruby.scm
@@ -3,6 +3,7 @@
 ;;; Copyright © 2014 Ludovic Courtès <ludo@gnu.org>
 ;;; Copyright © 2014, 2015 Mark H Weaver <mhw@netris.org>
 ;;; Copyright © 2014 David Thompson <davet@gnu.org>
+;;; Copyright © 2015 Ben Woodcroft <donttrustben@gmail.com>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -697,3 +698,34 @@ options and parsing command line flags.")
 net/http library.")
     (home-page "https://github.com/nicksieger/multipart-post")
     (license license:expat)))
+
+(define-public yaggo
+  (package
+   (name "yaggo")
+   (version "1.5.4")
+   (source (origin
+	    (method url-fetch)
+	    (uri (string-append
+		  "https://github.com/gmarcais/yaggo/archive/v"
+		  version ".tar.gz"))
+	    (file-name (string-append name "-" version ".tar.gz"))
+	    (sha256
+	     (base32
+	      "1mxfvrim03xg80agws9zdpk00r0kjpqhw3xbli0w8wvsnsa274y3"))))
+   (build-system ruby-build-system)
+   (arguments
+    `(#:tests? #f ;; no rake test, and Makefile in test/ appears malformed
+      #:phases
+      (modify-phases %standard-phases
+		     (replace 'build
+			      (lambda* _
+				(zero? (system* "rake"
+						"gem")))))))
+   (synopsis "Generate C++ command line parsers using getopt_long")
+   (description "Yaggo is a tool to generate command line parsers for
+C++.  Yaggo stands for 'Yet Another GenGetOpt' and is inspired by GNU
+Gengetopt.  It reads a configuration file describing the switches and argument
+for a C++ program and it generates one header file that parses the command
+line using getopt_long(3).")
+   (home-page "https://github.com/gmarcais/yaggo")
+   (license license:gpl3+)))
-- 
2.1.4

Re: [PATCH] Add yaggo.

[Pjotr Prins]

On Wed, Jun 24, 2015 at 02:35:03PM +1000, Ben Woodcroft wrote:
> Actually, I lie, this patch only sort of works. The issue is that it
> only works when a ruby package is also installed, GEM_PATH does not
> get set as part of the ruby-build-system for yaggo. The lib/ files
> are copied to what I gather is the correct place, but the env isn't
> right.
> 
> The same also appears to be true of other ruby packages e.g. ruby-hoe:
> $ guix package -i ruby-hoe
> ..
> ben@u:~/git/guix$ guix package --search-paths
> warning: failed to install locale: Invalid argument
> export PATH="/home/ben/.guix-profile/bin:/home/ben/.guix-profile/sbin"
> export PYTHONPATH="/home/ben/.guix-profile/lib/python3.4/site-packages"
> export PKG_CONFIG_PATH="/home/ben/.guix-profile/lib/pkgconfig:/home/ben/.guix-profile/share/pkgconfig"
> export GUILE_LOAD_PATH="/home/ben/.guix-profile/share/guile/site/2.0"
> export GUILE_LOAD_COMPILED_PATH="/home/ben/.guix-profile/share/guile/site/2.0"
> export CPATH="/home/ben/.guix-profile/include"
> export LIBRARY_PATH="/home/ben/.guix-profile/lib"
> export ACLOCAL_PATH="/home/ben/.guix-profile/share/aclocal"
> 
> i.e. no GEM_PATH entry, hence:

That is correct. The Ruby support system is still in development.

Adding the GEM_PATH is on the books as well as GEM_HOME and
GEM_SPEC_CACHE to have the gem and rspec tools work also outside GNU
Guix.

At the moment we are working on native gems (i.e. those that contain
C code). I am also planning for a rubygem-build-system which would
allow us to include gems with very simple package definitions, e.g.,
rather then

  (define-public ruby-i18n
    (package
      (name "ruby-i18n")
      (version "0.6.11")
      (source (origin
                (method url-fetch)
                (uri (string-append "https://github.com/svenfuchs/i18n/archive/v"
                                    version ".tar.gz"))
                (file-name (string-append name "-" version ".tar.gz"))
                (sha256
                 (base32
                  "1fdhnhh1p5g8vibv44d770z8nq208zrms3m2nswdvr54072y1m6k"))))
      (build-system ruby-build-system)
      (synopsis "Internationalization library for Ruby")
      (...)

we get

  (define-public ruby-i18n
    (package
      (name "ruby-i18n")
      (version "0.6.11")
      (source (origin
                (method gem-fetch)
                (file-name (string-append name "-" version ".gem"))
                (sha256
                 (base32
                  "1fdhnhh1p5g8vibv44d770z8nq208zrms3m2nswdvr54072y1m6k"))))
      (build-system rubygem-build-system)
      (synopsis "Internationalization library for Ruby")
      (...)

which would install directly from rubygems.org (including contained
dependencies when missing in the existing environment).

This would greatly facilitate adding Ruby gems to guix.

To get to this stage I need to better understand the guix source base,
something I am working on right now.

For now you can add the GEM_PATH with my script. It works for locating
installed gems and installing new ones in the right place. No need for rvm and
friends this way (native gems also build):

  https://github.com/pjotrp/guix-notes/blob/master/scripts/ruby-guix-env

If you run Ruby 2.2.2 you may want to update the paths to reflect that.

Pj.

Re: [PATCH] Add yaggo.

[Thompson, David]

On Wed, Jun 24, 2015 at 1:51 AM, Pjotr Prins <pjotr.public12@thebird.nl> wrote:
> On Wed, Jun 24, 2015 at 02:35:03PM +1000, Ben Woodcroft wrote:
>> Actually, I lie, this patch only sort of works. The issue is that it
>> only works when a ruby package is also installed, GEM_PATH does not
>> get set as part of the ruby-build-system for yaggo. The lib/ files
>> are copied to what I gather is the correct place, but the env isn't
>> right.
>>
>> The same also appears to be true of other ruby packages e.g. ruby-hoe:
>> $ guix package -i ruby-hoe
>> ..
>> ben@u:~/git/guix$ guix package --search-paths
>> warning: failed to install locale: Invalid argument
>> export PATH="/home/ben/.guix-profile/bin:/home/ben/.guix-profile/sbin"
>> export PYTHONPATH="/home/ben/.guix-profile/lib/python3.4/site-packages"
>> export PKG_CONFIG_PATH="/home/ben/.guix-profile/lib/pkgconfig:/home/ben/.guix-profile/share/pkgconfig"
>> export GUILE_LOAD_PATH="/home/ben/.guix-profile/share/guile/site/2.0"
>> export GUILE_LOAD_COMPILED_PATH="/home/ben/.guix-profile/share/guile/site/2.0"
>> export CPATH="/home/ben/.guix-profile/include"
>> export LIBRARY_PATH="/home/ben/.guix-profile/lib"
>> export ACLOCAL_PATH="/home/ben/.guix-profile/share/aclocal"
>>
>> i.e. no GEM_PATH entry, hence:
>
> That is correct. The Ruby support system is still in development.
>
> Adding the GEM_PATH is on the books as well as GEM_HOME and
> GEM_SPEC_CACHE to have the gem and rspec tools work also outside GNU
> Guix.

I don't know about $GEM_SPEC_CACHE, but $GEM_HOME cannot be a native
search path that is part of our ruby packages, because native search
paths are relative to store items, which are immutable.  My feeling is
that if the user wants to use the 'gem' utility instead of using Guix
packages, they're going to have to set an environment variable or two
by themselves.

> At the moment we are working on native gems (i.e. those that contain
> C code). I am also planning for a rubygem-build-system which would
> allow us to include gems with very simple package definitions, e.g.,
> rather then
>
>   (define-public ruby-i18n
>     (package
>       (name "ruby-i18n")
>       (version "0.6.11")
>       (source (origin
>                 (method url-fetch)
>                 (uri (string-append "https://github.com/svenfuchs/i18n/archive/v"
>                                     version ".tar.gz"))
>                 (file-name (string-append name "-" version ".tar.gz"))
>                 (sha256
>                  (base32
>                   "1fdhnhh1p5g8vibv44d770z8nq208zrms3m2nswdvr54072y1m6k"))))
>       (build-system ruby-build-system)
>       (synopsis "Internationalization library for Ruby")
>       (...)
>
> we get
>
>   (define-public ruby-i18n
>     (package
>       (name "ruby-i18n")
>       (version "0.6.11")
>       (source (origin
>                 (method gem-fetch)
>                 (file-name (string-append name "-" version ".gem"))
>                 (sha256
>                  (base32
>                   "1fdhnhh1p5g8vibv44d770z8nq208zrms3m2nswdvr54072y1m6k"))))
>       (build-system rubygem-build-system)
>       (synopsis "Internationalization library for Ruby")
>       (...)
>
> which would install directly from rubygems.org (including contained
> dependencies when missing in the existing environment).

Are you saying that it would bundle the dependencies if there were no
Guix packages for them?

> This would greatly facilitate adding Ruby gems to guix.

I must reiterate my concern about this approach to the wider
guix-devel audience.  From what I can see, the gem archives hosted on
rubygems.org are build artifacts and should probably be treated like
pre-built binaries.  They are not the complete, corresponding source
code.  Can anyone else weigh in here?  I understand the convenience of
using rubygems.org, but I really need some evidence that the archives
hosted there are complete, corresponding source code.

Thanks,

- Dave

Re: [PATCH] Add yaggo.

[Ricardo Wurmus]

> I must reiterate my concern about this approach to the wider
> guix-devel audience.  From what I can see, the gem archives hosted on
> rubygems.org are build artifacts and should probably be treated like
> pre-built binaries.  They are not the complete, corresponding source
> code.  Can anyone else weigh in here?

The gemspec file must list all files (either explicitly or via patterns)
that are to be distributed and thus needed at runtime.

As far as I can tell "gem push name.gem" can be used to upload anything
to rubygems.org that is considered a valid gem.  rubygems.org will only
extract the gemspec metadata and process them for later display[1].  The
parsed and possibly validated gemspecs are included in the gem when
doing "gem build name.gemspec".  For more info on what "gem build" does
see [2].

This means that using standard tools (unmodified "gem") the generated
gem is packaged according to the information in the gemspec file.  A gem
seems to be little more than a tar archive.  I would not consider this a
"build artifact", but release tarballs.  We don't have a problem with
using release tarballs over git clones for non-Ruby applications, even
though the tarballs may contain somewhat different sources (e.g. added
ChangeLog).

Of course, a gem created with a modified tool could contain more or less
than what the gemspec file declares.  But I would treat this in much the
same manner as I would treat broken release tarballs.

~~ Ricardo

[1]: https://github.com/rubygems/rubygems.org/blob/master/app/models/pusher.rb#L47
[2]: https://github.com/rubygems/rubygems/blob/master/lib/rubygems/package.rb

Re: [PATCH] Add yaggo.

[Pjotr Prins]

On Wed, Jun 24, 2015 at 08:32:51AM -0400, Thompson, David wrote:
> I don't know about $GEM_SPEC_CACHE, but $GEM_HOME cannot be a native
> search path that is part of our ruby packages, because native search
> paths are relative to store items, which are immutable.  My feeling is
> that if the user wants to use the 'gem' utility instead of using Guix
> packages, they're going to have to set an environment variable or two
> by themselves.

It is just a convenience. I believe GNU Guix should allow extra
package systems - like those of emacs. So point GEM_HOME to something
that is not immutable.

> > which would install directly from rubygems.org (including contained
> > dependencies when missing in the existing environment).
> 
> Are you saying that it would bundle the dependencies if there were no
> Guix packages for them?

Exactly.

> > This would greatly facilitate adding Ruby gems to guix.
> 
> I must reiterate my concern about this approach to the wider
> guix-devel audience.  From what I can see, the gem archives hosted on
> rubygems.org are build artifacts and should probably be treated like
> pre-built binaries.  They are not the complete, corresponding source
> code.  Can anyone else weigh in here?  I understand the convenience of
> using rubygems.org, but I really need some evidence that the archives
> hosted there are complete, corresponding source code.

Please see it as a migration path. There are tens of thousands of
useful gems out there with complex dependencies. There is no way we
are going to replace and test those overnight. Same for Python and
Perl modules (and all those other languages with their own module
system). I do favour pure Guix packages, also for gems, so we should
aim for replacing the most important ones over time. 

Making it hard(er) to install gems from GNU Guix for normal users will
only slow down adoption. Allow using rubygems for those gems that are
not (yet) supported by us. When enough Ruby people move to using Guix
for their development we may get rid of rubygems altogether. I would
love that. I already got rid of rvm :)

Nix experimented by converting all gems to Nix packages, that is
another possibility. But I think they proved it is hard and now
defunct (correct me if I am wrong). 

Pj.

Re: [PATCH] Add yaggo.

[Thompson, David]

On Wed, Jun 24, 2015 at 3:23 PM, Pjotr Prins <pjotr.public12@thebird.nl> wrote:
> On Wed, Jun 24, 2015 at 08:32:51AM -0400, Thompson, David wrote:
>> I don't know about $GEM_SPEC_CACHE, but $GEM_HOME cannot be a native
>> search path that is part of our ruby packages, because native search
>> paths are relative to store items, which are immutable.  My feeling is
>> that if the user wants to use the 'gem' utility instead of using Guix
>> packages, they're going to have to set an environment variable or two
>> by themselves.
>
> It is just a convenience. I believe GNU Guix should allow extra
> package systems - like those of emacs. So point GEM_HOME to something
> that is not immutable.
>
>> > which would install directly from rubygems.org (including contained
>> > dependencies when missing in the existing environment).
>>
>> Are you saying that it would bundle the dependencies if there were no
>> Guix packages for them?
>
> Exactly.

This will work against our goals.  It will create a lot of duplicated
files which will eat up extra disk space and make it difficult to
apply security patches.  The  job of a distribution is to deduplicate,
not bundle.  Furthermore, it will cover up the lack of such packages
in Guix and discourage people from packaging them.  Instead, we could
make a 'guix import rubygems' program that generates all the necessary
package boilerplate for the requested package and for the missing
dependencies.

>> > This would greatly facilitate adding Ruby gems to guix.
>>
>> I must reiterate my concern about this approach to the wider
>> guix-devel audience.  From what I can see, the gem archives hosted on
>> rubygems.org are build artifacts and should probably be treated like
>> pre-built binaries.  They are not the complete, corresponding source
>> code.  Can anyone else weigh in here?  I understand the convenience of
>> using rubygems.org, but I really need some evidence that the archives
>> hosted there are complete, corresponding source code.
>
> Please see it as a migration path. There are tens of thousands of
> useful gems out there with complex dependencies. There is no way we
> are going to replace and test those overnight. Same for Python and
> Perl modules (and all those other languages with their own module
> system). I do favour pure Guix packages, also for gems, so we should
> aim for replacing the most important ones over time.

Ricardo's response earlier in the thread has given me some confidence
that the gem archives on rubygems.org do qualify as the corresponding
source code.  That said, we really cannot use pre-built software under
any circumstances, because it compromises the project's goals of
reproducibility and the ethics of free software.  Fortunately for us,
rubygems.org seems to be OK, so let's adjust ruby-build-system as
needed.  It should work just fine, but we need to make sure that we
can still unpack the gem archive and run the test suite successfully
before installing to the output directory in the store.

> Making it hard(er) to install gems from GNU Guix for normal users will
> only slow down adoption. Allow using rubygems for those gems that are
> not (yet) supported by us. When enough Ruby people move to using Guix
> for their development we may get rid of rubygems altogether. I would
> love that. I already got rid of rvm :)

I'm not advocating that we prevent users from using 'gem'.  Right now,
it is possible for users to 'gem install bundler' and build Ruby
applications as they typically would.  I have done so on my GuixSD
machine.  So, let's package things the right way and let people just
use 'bundler' if they want some other stuff.

> Nix experimented by converting all gems to Nix packages, that is
> another possibility. But I think they proved it is hard and now
> defunct (correct me if I am wrong).

We of course wouldn't just auto-generate *everything* and dump it in
the repo.  There's still the human work of inspecting licenses,
writing synopses and descriptions, adding unspecified dependencies
(happens a lot), etc.

- Dave

Re: [PATCH] Add yaggo.

[Ricardo Wurmus]

Thompson, David <dthompson2@worcester.edu> writes:

> This will work against our goals.  It will create a lot of duplicated
> files which will eat up extra disk space and make it difficult to
> apply security patches.  The  job of a distribution is to deduplicate,
> not bundle.  Furthermore, it will cover up the lack of such packages
> in Guix and discourage people from packaging them.  Instead, we could
> make a 'guix import rubygems' program that generates all the necessary
> package boilerplate for the requested package and for the missing
> dependencies.

I agree with David that an importer for gems is the way to go here.  The
importer for Python has greatly simplified the process of writing
package definitions and for Ruby modules it should have a similar
effect.

We cannot let the perceived additional convenience of bundling stuff
override the underlying principles of functional package management with
Guix.  This may not be the fastest approach as it takes time to package
dependencies and untangle and break dependency cycles, but it is better
than needlessly bundling “binaries”.

> Ricardo's response earlier in the thread has given me some confidence
> that the gem archives on rubygems.org do qualify as the corresponding
> source code.  That said, we really cannot use pre-built software under
> any circumstances, because it compromises the project's goals of
> reproducibility and the ethics of free software.

+1

>> Making it hard(er) to install gems from GNU Guix for normal users will
>> only slow down adoption. Allow using rubygems for those gems that are
>> not (yet) supported by us. When enough Ruby people move to using Guix
>> for their development we may get rid of rubygems altogether. I would
>> love that. I already got rid of rvm :)
>
> I'm not advocating that we prevent users from using 'gem'.  Right now,
> it is possible for users to 'gem install bundler' and build Ruby
> applications as they typically would.  I have done so on my GuixSD
> machine.  So, let's package things the right way and let people just
> use 'bundler' if they want some other stuff.

I agree.  As long as the original method of using ‘gem’ and ‘bundler’
still works I don’t see any need for compromises.  It’s not like we’re
facing a technical problem we cannot solve.  It’s just that we haven’t
packaged a lot of Ruby stuff yet; same goes for Java stuff where the
same reasoning applies.

>> Nix experimented by converting all gems to Nix packages, that is
>> another possibility. But I think they proved it is hard and now
>> defunct (correct me if I am wrong).
>
> We of course wouldn't just auto-generate *everything* and dump it in
> the repo.  There's still the human work of inspecting licenses,
> writing synopses and descriptions, adding unspecified dependencies
> (happens a lot), etc.

And that’s where an importer would be very helpful, so that humans only
have to check and modify rather than write everything from scratch.

~~ Ricardo

Re: [PATCH] Add yaggo.

[Pjotr Prins]

To be clear (to avoid me being pigeon holed as the guy who wants
something that is not pure), we all agree on the following: We agree
to allow people to use bundler and gems if they want to. We agree that
gems can be packaged in Guix (as long as there is no binary code). And
we agree that we should build packages properly and reproducibly in
Guix. We agree an importer will be helpful. There is no disagreement
that I can tell.

What we have gained in this thread is that we allow ourselves to
construct packages directly from Ruby gems. A clear win for speeding
up building packages.

The only thing we (apparently) disagree on is setting the RUBY_HOME
path to mimic other distribution's behaviour and point it at a
non-immutable directory - to take away a (potential) threshold for
normal users.

Finally, I also have no problem of injecting multiple source gems in
one package, especially if they are not shared between packages. I
don't think that compromises purity. But that is my opinion. We don't
have to do it.

Let's close it at this. I am happy with what we agreed on.

Pj.

On Fri, Jun 26, 2015 at 08:56:03AM +0200, Ricardo Wurmus wrote:
> > Ricardo's response earlier in the thread has given me some confidence
> > that the gem archives on rubygems.org do qualify as the corresponding
> > source code.  That said, we really cannot use pre-built software under
> > any circumstances, because it compromises the project's goals of
> > reproducibility and the ethics of free software.
> 
> +1
> 
> >> Making it hard(er) to install gems from GNU Guix for normal users will
> >> only slow down adoption. Allow using rubygems for those gems that are
> >> not (yet) supported by us. When enough Ruby people move to using Guix
> >> for their development we may get rid of rubygems altogether. I would
> >> love that. I already got rid of rvm :)
> >
> > I'm not advocating that we prevent users from using 'gem'.  Right now,
> > it is possible for users to 'gem install bundler' and build Ruby
> > applications as they typically would.  I have done so on my GuixSD
> > machine.  So, let's package things the right way and let people just
> > use 'bundler' if they want some other stuff.
> 
> I agree.  As long as the original method of using ‘gem’ and ‘bundler’
> still works I don’t see any need for compromises.  It’s not like we’re
> facing a technical problem we cannot solve.  It’s just that we haven’t
> packaged a lot of Ruby stuff yet; same goes for Java stuff where the
> same reasoning applies.
> 
> >> Nix experimented by converting all gems to Nix packages, that is
> >> another possibility. But I think they proved it is hard and now
> >> defunct (correct me if I am wrong).
> >
> > We of course wouldn't just auto-generate *everything* and dump it in
> > the repo.  There's still the human work of inspecting licenses,
> > writing synopses and descriptions, adding unspecified dependencies
> > (happens a lot), etc.
> 
> And that’s where an importer would be very helpful, so that humans only
> have to check and modify rather than write everything from scratch.

Re: [PATCH] Add yaggo.

[Thompson, David]

On Wed, Jun 24, 2015 at 12:35 AM, Ben Woodcroft <b.woodcroft@uq.edu.au> wrote:
> Actually, I lie, this patch only sort of works. The issue is that it only
> works when a ruby package is also installed, GEM_PATH does not get set as
> part of the ruby-build-system for yaggo. The lib/ files are copied to what I
> gather is the correct place, but the env isn't right.
>
> The same also appears to be true of other ruby packages e.g. ruby-hoe:

This is the expected, correct behavior.  The native search path
$GEM_PATH is defined in the ruby package, like so:

    (native-search-paths
         (list (search-path-specification
                (variable "GEM_PATH")
               (files (list (string-append "lib/ruby/gems/"
                                            (version-major+minor version)
                                            ".0"))))))

Thus, you need ruby to be a part of your profile.  Perhaps ruby should
be a propagated input for packages with ruby executables, or scripts
could be wrapped in another script that set the correct environment
variables.

- Dave

Re: [PATCH] Add yaggo.

[Ben Woodcroft]

On 24/06/15 22:19, Thompson, David wrote:
> Perhaps ruby should
> be a propagated input for packages with ruby executables, or scripts
> could be wrapped in another script that set the correct environment
> variables.
A naive question - I don't believe that this is required for e.g. python 
packages that have executables and the somewhat analogous PYTHONPATH. 
Why is Ruby different?

Thanks,
ben

Re: [PATCH] Add yaggo.

[Thompson, David]

On Wed, Jun 24, 2015 at 7:41 PM, Ben Woodcroft <b.woodcroft@uq.edu.au> wrote:
>
>
> On 24/06/15 22:19, Thompson, David wrote:
>>
>> Perhaps ruby should
>> be a propagated input for packages with ruby executables, or scripts
>> could be wrapped in another script that set the correct environment
>> variables.
>
> A naive question - I don't believe that this is required for e.g. python
> packages that have executables and the somewhat analogous PYTHONPATH. Why is
> Ruby different?

The Python build system creates wrappers around all executables that
sets the proper PYTHONPATH.  I'm not a big fan of this approach, but
something similar will probably need to be done for Ruby if we can't
find a better way.

- Dave

Re: [PATCH] Add yaggo.

[Mark H Weaver]

Ben Woodcroft <b.woodcroft@uq.edu.au> writes:

> From d220bdeac89660108de96a96107daf89182310e0 Mon Sep 17 00:00:00 2001
> From: Ben Woodcroft <donttrustben@gmail.com>
> Date: Wed, 24 Jun 2015 14:32:26 +1000
> Subject: [PATCH] gnu: Add yaggo.
>
> * gnu/packages/ruby.scm (yaggo): New variable.
> ---
>  gnu/packages/ruby.scm | 32 ++++++++++++++++++++++++++++++++
>  1 file changed, 32 insertions(+)
>
> diff --git a/gnu/packages/ruby.scm b/gnu/packages/ruby.scm
> index af87cf5..19006d3 100644
> --- a/gnu/packages/ruby.scm
> +++ b/gnu/packages/ruby.scm
> @@ -3,6 +3,7 @@
>  ;;; Copyright © 2014 Ludovic Courtès <ludo@gnu.org>
>  ;;; Copyright © 2014, 2015 Mark H Weaver <mhw@netris.org>
>  ;;; Copyright © 2014 David Thompson <davet@gnu.org>
> +;;; Copyright © 2015 Ben Woodcroft <donttrustben@gmail.com>
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -697,3 +698,34 @@ options and parsing command line flags.")
>  net/http library.")
>      (home-page "https://github.com/nicksieger/multipart-post")
>      (license license:expat)))
> +
> +(define-public yaggo
> +  (package
> +   (name "yaggo")
> +   (version "1.5.4")
> +   (source (origin
> +	    (method url-fetch)
> +	    (uri (string-append
> +		  "https://github.com/gmarcais/yaggo/archive/v"
> +		  version ".tar.gz"))
> +	    (file-name (string-append name "-" version ".tar.gz"))
> +	    (sha256
> +	     (base32
> +	      "1mxfvrim03xg80agws9zdpk00r0kjpqhw3xbli0w8wvsnsa274y3"))))

Please change the tabs to spaces.

> +   (build-system ruby-build-system)
> +   (arguments
> +    `(#:tests? #f ;; no rake test, and Makefile in test/ appears malformed

Just one semicolon there, please.  Our convention, borrowed from
<http://mumble.net/~campbell/scheme/style.txt>, is to use one semicolon
for "margin comments", i.e. comments to the right of the code, and two
semicolons for comments on their own line preceding code.

It's made more important by the fact that formatting commands in Emacs
Lisp editing modes will act differently depending on how many semicolon
are present.

> +      #:phases
> +      (modify-phases %standard-phases
> +		     (replace 'build

Please align the "(" under the "o" in "modify-phases"

> +			      (lambda* _

You can use plain 'lambda' here.

> +				(zero? (system* "rake"
> +						"gem")))))))

It would look better to move "gem" to the preceeding line.  Better yet,
how about putting the entire 'replace' on one line, like this:

      (modify-phases %standard-phases
        (replace 'build (lambda _ (zero? (system* "rake" "gem")))))))

Normally I use more whitespace, but in this case I think it's perfectly
readable.  What do you think?

> +   (synopsis "Generate C++ command line parsers using getopt_long")
> +   (description "Yaggo is a tool to generate command line parsers for
> +C++.  Yaggo stands for 'Yet Another GenGetOpt' and is inspired by GNU
> +Gengetopt.  It reads a configuration file describing the switches and argument
> +for a C++ program and it generates one header file that parses the command
> +line using getopt_long(3).")
> +   (home-page "https://github.com/gmarcais/yaggo")
> +   (license license:gpl3+)))

Can you send an updated patch?

    Thanks,
      Mark

Re: [PATCH] Add yaggo.

[Ben Woodcroft]

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

On 05/07/15 17:33, Mark H Weaver wrote:
> Normally I use more whitespace, but in this case I think it's perfectly
> readable.  What do you think?
Sure.

The tab issues were caused by my using the scheme mode of emacs rather 
than the guile one, and shouldn't happen any more. Apparently also when 
you search for space in emacs it also highlights tabs...
> Can you send an updated patch?
Attached, but actually I have two questions:
1. should the name of this be yaggo or ruby-yaggo?
2. should ruby be a propagated input, or the bin/ script wrapped as 
suggested otherwise in this thread?

Happy for you to push if you think the patch is OK - it does not change 
strategy from the original.

Thanks,
ben

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-gnu-Add-yaggo.patch --]
[-- Type: text/x-patch; name="0001-gnu-Add-yaggo.patch", Size: 2287 bytes --]

From df26cd16f04f322bdf1685072f21dc2de67796a8 Mon Sep 17 00:00:00 2001
From: Ben Woodcroft <donttrustben@gmail.com>
Date: Sun, 5 Jul 2015 21:13:33 +1000
Subject: [PATCH] gnu: Add yaggo.

* gnu/packages/ruby.scm (yaggo): New variable.
---
 gnu/packages/ruby.scm | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/gnu/packages/ruby.scm b/gnu/packages/ruby.scm
index af87cf5..58f8dba 100644
--- a/gnu/packages/ruby.scm
+++ b/gnu/packages/ruby.scm
@@ -3,6 +3,7 @@
 ;;; Copyright © 2014 Ludovic Courtès <ludo@gnu.org>
 ;;; Copyright © 2014, 2015 Mark H Weaver <mhw@netris.org>
 ;;; Copyright © 2014 David Thompson <davet@gnu.org>
+;;; Copyright © 2015 Ben Woodcroft <donttrustben@gmail.com>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -697,3 +698,34 @@ options and parsing command line flags.")
 net/http library.")
     (home-page "https://github.com/nicksieger/multipart-post")
     (license license:expat)))
+
+(define-public yaggo
+  (package
+   (name "yaggo")
+   (version "1.5.4")
+   (source (origin
+             (method url-fetch)
+             (uri (string-append
+                   "https://github.com/gmarcais/yaggo/archive/v"
+                   version ".tar.gz"))
+             (file-name (string-append name "-" version ".tar.gz"))
+             (sha256
+              (base32
+               "1mxfvrim03xg80agws9zdpk00r0kjpqhw3xbli0w8wvsnsa274y3"))))
+   (build-system ruby-build-system)
+   (arguments
+    `(
+      ;; No rake test, and Makefile in test/ appears malformed.
+      ;; See https://github.com/gmarcais/yaggo/issues/3
+      #:tests? #f
+      #:phases
+      (modify-phases %standard-phases
+        (replace 'build (lambda* _ (zero? (system* "rake" "gem")))))))
+   (synopsis "Generate C++ command line parsers using getopt_long")
+   (description "Yaggo is a tool to generate command line parsers for C++.
+Yaggo stands for 'Yet Another GenGetOpt' and is inspired by GNU Gengetopt.  It
+reads a configuration file describing the switches and argument for a C++
+program and it generates one header file that parses the command line using
+getopt_long(3).")
+   (home-page "https://github.com/gmarcais/yaggo")
+   (license license:gpl3+)))
-- 
2.1.4