unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Prafulla Giri <pratheblackdiamond@gmail.com>
To: Julien Lepiller <julien@lepiller.eu>
Cc: 42948@debbugs.gnu.org
Subject: bug#42948: (wrap-program) bug
Date: Thu, 20 Aug 2020 21:00:29 +0545	[thread overview]
Message-ID: <CAFw+=j3FhPEE=KNfDWg0sktrzfafabkmvnpnUS=XZ+WWUb3TRw@mail.gmail.com> (raw)
In-Reply-To: <20200820143158.51e8b321@tachikoma.lepiller.eu>


[-- Attachment #1.1: Type: text/plain, Size: 4122 bytes --]

Yes, you are correct. This turned out to be a false alarm. I poked around
with the definition, and, just like you said, everything works.

`ronn` not running was a gempspec issue that I have resolved in the package
definition (patch attached).

Thank you very much for clearing the matter out!

On Thu, Aug 20, 2020 at 6:17 PM Julien Lepiller <julien@lepiller.eu> wrote:

> Le Thu, 20 Aug 2020 17:44:01 +0545,
> Prafulla Giri <pratheblackdiamond@gmail.com> a écrit :
>
> > Esteemed maintainers,
> >
> > It seems that (wrap-program ...) over-writes the previous wrapping of
> > a package done by the build system.
> >
> > This does not happen for many (wrap-programs) called in the
> > modify-phases section of the package definition itself.
> >
> > Attached is a package definition for ruby-ronn-ng, that demonstrates
> > this issue. The custom (wrap-program)-s
> > called from the package definition seem to over-write the definitions
> > of GEM_ENV as made by the 'wrap %standard-phase
> > of the ruby-build system.
> > The wrappings made by 'wrap %standard-phase can be seen during the
> > custom 'DEBUG phase. The subsequent 'wrap-program1
> > and 'wrap-program2 add more environment variables to the wrapping,
> > but on checking the contents of `which ronn`, once
> > it is installed (using `less $(which ronn)`), it can be verified that
> > the GEM_ENV package definitions have been overwritten.
> >
> > This may just be a ruby-build-system issue. Or perhaps it might be
> > something that permeates over a few more build systems.
> > That still remains to be tested.
> >
> > Attached are a few different versions of the package definitions for
> > ruby-ronn-ng for the ease of those who would like to
> > verify this.
> > 1. ruby-ronn-ng-standalone.scm : To be tested using `guix
> > time-machine -- build --verbosity=2
> > --file=ruby-ronn-ng-standalone.scm`[1] 2. ruby-ronn-ng.scm : To be
> > appended to the end of the gnu/packages/ruby.scm file in local guix
> > checkout, and be tested using the local version
> > 3. ruby-ronn-ng.patch : To be applied to local guix checkout
> >
> > [1] - This package definition needs ruby-mustache, which has only
> > recently been added to guix. Hence, the time-machine.
> >
> > NOTE: `ronn` does not work even with `propagated-inputs`. See this
> > patch as to why:
> >
> https://aur.archlinux.org/cgit/aur.git/tree/0001-allow-mustache-1.0.patch?h=ruby-ronn-ng
>
> Hi,
>
> From what I see, there is no issue here (unless I'm missing something).
> In the built package, I see bin/ronn is a shell wrapper that defines
> the PATH and FOO environment variables and calls bin/.ronn-real.
> bin/.ronn-real itself is a ruby script that defines GEM_PATH and calls
> bin/.real/ronn, which is the actual program.
>
> I don't see anything wrong with that, but I'm not a ruby expert. In
> fact, when running ronn (from its store path directly), I see the
> following error:
>
>
> /gnu/store/9yqh0g1p5bmxar8dlfp84j4py3j631jv-ruby-2.6.5/lib/ruby/2.6.0/rubygems/dependency.rb:313:in
> `to_specs': Could not find 'mustache' (>= 0.7.0, ~> 0.7) - did find:
> [mustache-1.1.1] (Gem::MissingSpecVersionError) Checked in
>
> 'GEM_PATH=/gnu/store/l8jicf1ibzrgff754mvbc5k14fa62s7a-ruby-ronn-ng-0.9.1/lib/ruby/vendor_ruby:/gnu/store/9yqh0g1p5bmxar8dlfp84j4py3j631jv-ruby-2.6.5/lib/ruby/vendor_ruby:/gnu/store/w1a9ndhvvbw76g19fgx4j78kx3aghi4k-ruby-kramdown-2.3.0/lib/ruby/vendor_ruby:/gnu/store/jfbzrfd7i8x46q9c8sw26av6kx7jyr3c-ruby-mustache-1.1.1/lib/ruby/vendor_ruby:/gnu/store/0wsy4yymr5m0wzms0qv5ak5q21g8c6hs-ruby-nokogiri-1.10.9/lib/ruby/vendor_ruby:/gnu/store/7ncf7v5prhv4ir8bgdlxa1rz8ph5mlry-ruby-pkg-config-1.2.5/lib/ruby/vendor_ruby:/gnu/store/924np2k8f04lfjr6l9hzic7drah8bgbb-ruby-mini-portile-2.4.0/lib/ruby/vendor_ruby:/gnu/store/9yqh0g1p5bmxar8dlfp84j4py3j631jv-ruby-2.6.5/lib/ruby/gems/2.6.0',
> execute `gem env` for more information
>
> which suggests that the GEM_PATH is set correctly (after all it found
> mustache), but the dependencies do not have the expected version. Does
> that make sense?
>

[-- Attachment #1.2: Type: text/html, Size: 4970 bytes --]

[-- Attachment #2: ronn-ng-working.patch --]
[-- Type: text/x-patch, Size: 2085 bytes --]

diff --git a/gnu/packages/ruby.scm b/gnu/packages/ruby.scm
index 010028082a..0a245855ee 100644
--- a/gnu/packages/ruby.scm
+++ b/gnu/packages/ruby.scm
@@ -11659,3 +11659,46 @@ which snapshots to consider and what files to include.")
 defined in @file{.travis.yml} on your local machine, using @code{rvm},
 @code{rbenv}, or @code{chruby} to test different versions of Ruby.")
     (license license:expat)))
+
+(define-public ruby-ronn-ng
+  (package
+    (name "ruby-ronn-ng")
+    (version "0.9.1")
+    (source
+     (origin
+       (method url-fetch)
+       (uri (rubygems-uri "ronn-ng" version))
+       (sha256
+        (base32
+         "1slxfg57cabmh98fw507z4ka6lwq1pvbrqwppflxw6700pi8ykfh"))))
+    (build-system ruby-build-system)
+    (arguments
+     `(#:phases
+       (modify-phases %standard-phases
+         (add-after
+             'extract-gemspec 'fix-gemspec-mustache
+           (lambda _
+             (substitute* "ronn-ng.gemspec"
+               (("(<mustache>.freeze.*~>).*(\".*$)" all start end)
+                (string-append start " 1.0" end)))
+             #t))
+         (add-after
+             'wrap 'wrap-program
+           (lambda* (#:key outputs #:allow-other-keys)
+             (let ((prog (string-append (assoc-ref %outputs "out") "/bin/ronn")))
+               (begin (display %build-inputs)(newline))
+               (wrap-program prog
+                 `("PATH" ":" suffix ,(map (lambda (exp_inpt)
+                                             (string-append (assoc-ref %build-inputs exp_inpt) "/bin"))
+                                           '("ruby-kramdown" "ruby-mustache" "ruby-nokogiri")))))
+             #t)) )))
+    (inputs
+     `(("ruby-kramdown" ,ruby-kramdown)
+       ("ruby-mustache" ,ruby-mustache)
+       ("ruby-nokogiri" ,ruby-nokogiri)))
+    (synopsis
+     "Ronn-NG builds manuals in HTML and Unix man page format from Markdown.")
+    (description
+     "Ronn-NG builds manuals in HTML and Unix man page format from Markdown.")
+    (home-page "https://github.com/apjanke/ronn-ng")
+    (license license:expat)))

  reply	other threads:[~2020-08-20 15:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-20 11:59 bug#42948: (wrap-program) bug Prafulla Giri
2020-08-20 12:31 ` Julien Lepiller
2020-08-20 15:15   ` Prafulla Giri [this message]
2020-08-20 16:57 ` Julien Lepiller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFw+=j3FhPEE=KNfDWg0sktrzfafabkmvnpnUS=XZ+WWUb3TRw@mail.gmail.com' \
    --to=pratheblackdiamond@gmail.com \
    --cc=42948@debbugs.gnu.org \
    --cc=julien@lepiller.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).