Le Thu, 20 Aug 2020 17:44:01 +0545, Prafulla Giri <[email protected]> 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?
