On 8 May 2018 at 11:47, Sam Ruby <[email protected]> wrote: > On Tue, May 8, 2018 at 6:22 AM, sebb <[email protected]> wrote: >> On 8 May 2018 at 11:09, Sam Ruby <[email protected]> wrote: >>> On Tue, May 8, 2018 at 6:03 AM, sebb <[email protected]> wrote: >>>> On 8 May 2018 at 10:55, Sam Ruby <[email protected]> wrote: >>>>> On Tue, May 8, 2018 at 5:45 AM, sebb <[email protected]> wrote: >>>>>> On 8 May 2018 at 10:39, Sam Ruby <[email protected]> wrote: >>>>>>> On Tue, May 8, 2018 at 4:57 AM, sebb <[email protected]> wrote: >>>>>>>> >>>>>>>> Are you sure the shortcut causes a failure? >>>>>>> >>>>>>> Following is from the syslog: >>>>>>> >>>>>>> whimsy-asf-0.0.77/lib/whimsy/asf/svn.rb:60:in `find!': Unable to find >>>>>>> svn checkout for https://svn.apache.org/repos/foundation_board >>>>>>> (Exception) >>>>>> >>>>>> That line number (60) does not agree with the current code. >>>>> >>>>> Good catch! >>>>> >>>>>> Maybe the installed version of the library is out of date? >>>>> >>>>> It certainly is: https://rubygems.org/gems/whimsy-asf/versions/0.0.77, >>>>> but that shouldn't be used: >>>>> >>>>> https://github.com/apache/whimsy/blob/master/www/board/agenda/Gemfile#L3 >>>>> >>>>> I could certainly build and push out a new version of whimsy-asf, but >>>>> that would only be a temporary solution. >>>> >>>> I think we need to remove the Gem from the system entirely. >>> >>> Then it would fail a different way :-) >> >> That would also need to be fixed. > > I may not have been clear: fixing the underlying problem (the > dependency not being picked up from the path specified) is needed > either way. > >>>> I assume most code is not using the Gem otherwise we would have seen >>>> more issues. >>>> So it might be feasible to remove it (or at least rename it) and see >>>> what breaks. >>>> >>>> However if there is a way to tell the service to pick up the library >>>> from the source, that should be added first. >>> >>> The way to do that is: >>> >>> gem 'whimsy-asf', asf_version, path: File.expand_path(root, __FILE__) >>> >>> The question is: why isn't the version_file being found (in the if >>> statement a few lines before this code) when run as a service? This >>> file is found when run from the command line. >> >> I don't know. >> >> Does the library have to be a Gem? > > A gem is just a library with a well know directory layout. The right > question isn't whether or not it has to be a gem, but where should the > gem be found? > > We are using bundler for dependencies. Specifying the path on the > 'gem' statement should (and generally does, except in this case for > unknown reasons) work: > > http://bundler.io/v1.2/man/gemfile.5.html#PATH-path- > >> Is it not possible to define the RUBY path appropriately so code picks >> up the source correctly? > > Bundler overrides rubypath.
I tried the following: SetEnv RUBYLIB /srv/whimsy/lib This worked OK to find the Whimsy library code even though I had deleted the gem. I deleted some other stuff so the apps don't get very far. The Passenger error output includes the following: RUBYLIB = /usr/local/Cellar/ruby/2.5.0/lib/ruby/2.5.0:/srv/whimsy/lib ... BUNDLER_ORIG_RUBYLIB = /srv/whimsy/lib This looks to me as though it should be possible to use RUBYLIB as well as bundler. I think it's important not to end up with a stale whimsy Gem again, and one such way might be to never define whimsy as a Gem. >> IMO we should only use Gems for external bundled code. > > The issue is the bundler overrides rubypath. > > If you go to whimsy/board/agenda, and type 'bundle update' you should > see a line like: > > Using whimsy-asf 0.0.77 from source at `/Users/rubys/git/whimsy` > > If you look in Gemfile.lock in that directory, you should see something like: > > PATH > remote: /Users/rubys/git/whimsy > specs: > whimsy-asf (0.0.77) > > We clearly are picking up the code from the wrong place. The question > that remains is: why? > > - Sam Ruby
