On Wed, Jan 13, 2016 at 11:12 AM, sebb <seb...@gmail.com> wrote: > On 13 January 2016 at 13:09, Sam Ruby <ru...@intertwingly.net> wrote: >> On Wed, Jan 13, 2016 at 7:29 AM, sebb <seb...@gmail.com> wrote: >>> On 13 January 2016 at 11:53, Sam Ruby <ru...@intertwingly.net> wrote: >>>> On Wed, Jan 13, 2016 at 6:13 AM, sebb <seb...@gmail.com> wrote: >>>>> There does not seem to be much (if any) advantage of using a Gem to >>>>> hold the common Whimsy code. >>>>> >>>>> There are some disadvantages: >>>>> - testing changes to the library code is harder >>>>> - Gem has to be generated, uploaded and deployed >>>>> - having the Gem as well as the source code on the same system is >>>>> confusing as they may differ >>>>> >>>>> I think it would be much simpler to reference the library code using a >>>>> relative RUBYLIB definition. >>>>> >>>>> This will mean some changes in order to provide version tags, but >>>>> those need to be done anyway as the code currently assumes SVN is >>>>> being used. >>>> >>>> Gems can be locally installed, and Gemfiles can be used to locate >>>> them. The following change should allow you to do what you want: >>>> >>>> https://github.com/apache/whimsy/commit/7d09b579bf02a186a739ad72ce8096640388dec8 >>>> >>>> Should it work out, all that would need to be done is to add "require >>>> 'bundler/setup'" to the main executables. >>>> >>>> I don't know if this completely addresses the problem, but it is a >>>> reasonable first step in that it allows code to be migrated one >>>> application at a time. >>> >>> Still seems unnecessarily complicated, and there are then potentially >>> 3 different versions of the library code: >>> - lib/whimsy >>> - local Gem >>> - system Gem >>> >>> Defining RUBYLIB works for me locally, and can be done in a login script. >> >> Did you give it a try? Assuming you have ~/.whimsy set up, and have >> installed the bundler gem, the following should "just work" with no >> RUBYLIB, no login script: >> >> $ git clone https://github.com/apache/whimsy.git >> $ ruby whimsy/www/roster/public_committee_info.rb > > Fails with: > > $ ruby whimsy/www/roster/public_committee_info.rb > /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in > `require': cannot load such file -- whimsy/asf (LoadError) > from > /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in > `require' > from whimsy/www/roster/public_committee_info.rb:4:in `<main>' > > Turns out it works if I do: > > $ cd whimsy > $ ruby www/roster/public_committee_info.rb
OK, that's kinda weird. I've reproduced this, and verified that you can run from the whimsy, whimsy/www, and whimsy/roster directories. And that when you do so, you will pick up your local copy of lib directory. While weird, it doesn't seem unreasonable to expect you to be in the directory structure of the application you are trying to test. >> In any case, the change is live and >> https://whimsy-test.apache.org/public/committee-info.json was updated, > > However AFAICT it still contains the bug. > Or maybe you meant that only the Gem change is now live, not the parsing bug? public_committee_info.rb, as deployed, should no longer be dependent on the whimsy-asf gem. Instead, it should make use of the code as it currently exists in the whimsy/lib directory. As a committer, you should be able to make a change, test it locally, push it out to GitHub, and have it deployed automatically for you. I realize that you are focused on getting this bug fixed. I appreciate that. Please recognize that I am focused on NOT BEING THE ONLY PERSON WHO CAN DO ALL THE WORK. What, if anything, is holding you up from developing a change, testing it locally on your machine, pushing your change to GitHub, and having it deploy automatically on whimsy-test.apache.org? If you do that, I would very much appreciate it. At that point, I'll manually copy the change over to whimsy.apache.org as it is not worth it to set up auto-deployment there as it is going away. And once it does go away, you should be able to develop and deploy changes without my assistance. >> Daniel has indicated that MATT is operational. At this point, you >> should be good to go. And if you have changes you want to make to >> further move away from having a gem, feel free to make them. Daniel tells me that you are not set up yet. Is there a problem? - Sam Ruby
