Backgroundrb devel - Dec 2006 - Is there a way to make backgroundrb 0.2.1 fail silently on win32?

After upgrading to backgroundrb 0.2.x, Rails barfs lstat errors left and
right when using the console or webrick or mongrel on win32.  We run our
site on a Linux server, so I''m not trying to get backgroundrb to work
on a
win32 machine.  I just want to quietly stop loading itself if it detects
that it''s on a win32 machine so that the rest of Rails can continue to
load.

Most of our developers are working on win32 machines and they''re
focused on
other parts of our site, so it would be nice for them to be able to continue
working on their bits of code even though backgroundrb is sitting dormant in
the vendor/plugins directory.

I tried searching for a way to disable certain plugins in
config/environment.rb, but it appears this idea was batted down by DHH:
http://dev.rubyonrails.org/ticket/5468

Is there something I can do to monkey patch my svn:externals''d link to
backgroundrb 0.2.1 to prevent it from loading itself if PLATFORM =~
/win32/i?

I could unlink backgroundrb from the devjavu svn repository and do the patch
myself on the code, but I''d prefer not to store backgroundrb in my own
SVN
repo.

Any ideas?

Thanks in advance,
eden
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20061215/3e15eb45/attachment-0001.html

On Dec 14, 2006, at 9:55 AM, Eden Li wrote:
> After upgrading to backgroundrb 0.2.x, Rails barfs lstat errors  
> left and right when using the console or webrick or mongrel on  
> win32.  We run our site on a Linux server, so I''m not trying to
get
> backgroundrb to work on a win32 machine.  I just want to quietly  
> stop loading itself if it detects that it''s on a win32 machine so
> that the rest of Rails can continue to load.
>
> Most of our developers are working on win32 machines and they''re  
> focused on other parts of our site, so it would be nice for them to  
> be able to continue working on their bits of code even though  
> backgroundrb is sitting dormant in the vendor/plugins directory.
>
> I tried searching for a way to disable certain plugins in config/ 
> environment.rb, but it appears this idea was batted down by DHH:  
> http://dev.rubyonrails.org/ticket/5468
>
> Is there something I can do to monkey patch my svn:externals''d
link
> to backgroundrb 0.2.1 to prevent it from loading itself if PLATFORM  
> =~ /win32/i?
>
> I could unlink backgroundrb from the devjavu svn repository and do  
> the patch myself on the code, but I''d prefer not to store  
> backgroundrb in my own SVN repo.
>
> Any ideas?
>
> Thanks in advance,
> eden
>
	I don''t know of any way to do conditional svn:externals sorry. Maybe  
for now you could remove backgroundrb from your svn repo and set  
svn:ignore on it. Then just have it in there locally but not checking  
it in. Then you could also keep a copy of backgroundrb on the server  
and have your deploy cap task symlink it into the app after deploy.

Cheers-

-- Ezra Zygmuntowicz 
-- Lead Rails Evangelist
-- ez at engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)

> 	I don''t know of any way to do conditional svn:externals sorry.
Maybe
> for now you could remove backgroundrb from your svn repo and set  
> svn:ignore on it. Then just have it in there locally but not checking  
> it in. Then you could also keep a copy of backgroundrb on the server  
> and have your deploy cap task symlink it into the app after deploy.
since all Rails loads is the lib/ files - I think we can make it
conditional on platform - if you submit a ticket we can look at it for
the next release.

/skaar
-- 
----------------------------------------------------------------------
|\|\             where in the       |          s_u_b_s_t_r_u_c_t_i_o_n 
| | >===========  W.A.S.T.E.        |                  genarratologies 
|/|/    (_)     is the wisdom       |                  skaar at waste.org
----------------------------------------------------------------------

>       I don''t know of any way to do conditional svn:externals
sorry. Maybe
> for now you could remove backgroundrb from your svn repo and set
> svn:ignore on it. Then just have it in there locally but not checking
> it in. Then you could also keep a copy of backgroundrb on the server
> and have your deploy cap task symlink it into the app after deploy.
This is a possibility, but it requires me to have to go onto my server
and maintain a separate directory of files that aren''t versioned along
with the rest of the project.  It''s not that bad, but I figured out a
way to get the desired effect without resorting to this.

Rails puts the app''s lib/ ahead of all plugins in the library search
path, so I created a file that shares the same name of the file that
gets loaded in backgroundrb''s init.rb (middleman_rails_init.rb) and
placed it under my lib directory.  This file will exit silently if it
finds itself being loaded on win32 otherwise it''ll continue loading
the appropriate middleman_rails_init from backgroundrb.
> since all Rails loads is the lib/ files - I think we can make it
> conditional on platform - if you submit a ticket we can look at it for
> the next release.
I''ve filed a ticket and attached a patch for init.rb:
http://backgroundrb.devjavu.com/projects/backgroundrb/ticket/42

If one has all the calls to BackgrounDRb isolated in a few Rails
models. For example I have app/model/nucleus.rb - which does all the
interactions with workers. One could solve such a  problem by using
Rails mock objects. I would just have to place a mocking model into
app/test/mocks/development/nucleus.rb, and it will use that model
instead when the application is running in the development
environment.

For your case, the developers could run Rails with
--environment=development on win32. On linux you could be run it with
--environment=testing or --environment=production, so that
BackgrounDRb is used.


Question for Ezra: Will BackgrounDRb work on Windows eventually?

On 12/14/06, Eden Li <eden.li at gmail.com> wrote:
> After upgrading to backgroundrb 0.2.x, Rails barfs lstat errors left and
> right when using the console or webrick or mongrel on win32.  We run our
> site on a Linux server, so I''m not trying to get backgroundrb to
work on a
> win32 machine.  I just want to quietly stop loading itself if it detects
> that it''s on a win32 machine so that the rest of Rails can
continue to load.
>
> Most of our developers are working on win32 machines and they''re
focused on
> other parts of our site, so it would be nice for them to be able to
continue
> working on their bits of code even though backgroundrb is sitting dormant
in
> the vendor/plugins directory.
>
> I tried searching for a way to disable certain plugins in
> config/environment.rb, but it appears this idea was batted down by DHH:
> http://dev.rubyonrails.org/ticket/5468
>
> Is there something I can do to monkey patch my svn:externals''d
link to
> backgroundrb 0.2.1 to prevent it from loading itself if PLATFORM =~
> /win32/i?
>
> I could unlink backgroundrb from the devjavu svn repository and do the
patch
> myself on the code, but I''d prefer not to store backgroundrb in my
own SVN
> repo.
>
> Any ideas?
>
> Thanks in advance,
> eden
>
>
>
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>
>

-- 
--------------------------------------------
Aleksandr Levchuk
University of California, Riverside
1-951-368-0004
--------------------------------------------

Interesting solution, and it would probably work if I wasn''t running
into exceptions even before the Rails models get loaded fully.

As mentioned in my previous mail, I discovered Rails was trying to run
vendor/plugins/backgroundrb/init.rb which will load
vendor/plugins/backgroundrb/lib/middleman_rails_init.rb which always
throws on win32.  I also explain how I got around it in that mail.

On 12/16/06, Aleksandr Levchuk <alevchuk at gmail.com>
wrote:
> If one has all the calls to BackgrounDRb isolated in a few Rails
> models. For example I have app/model/nucleus.rb - which does all the
> interactions with workers. One could solve such a  problem by using
> Rails mock objects. I would just have to place a mocking model into
> app/test/mocks/development/nucleus.rb, and it will use that model
> instead when the application is running in the development
> environment.
>
> For your case, the developers could run Rails with
> --environment=development on win32. On linux you could be run it with
> --environment=testing or --environment=production, so that
> BackgrounDRb is used.