I looked into this a while ago when someone else had the same issue. It's odd that ThinkingSphinx is loading a lib into memory that is not being used. (Apparently a ticket is open to resolve that.) I looked into ways to address this but I could not come up with a nice clean way due to the way the DelayedJob support was originally added.

One easy fix might be to undefined the Delayed const before you load email-spec. Doing that would prevent email-spec from loading the background process module.

So.. in short there is way, currently, to disable this. I would like to see a patch that forces DelatedJob people to require 'email-spec/delayed_job' or something. I went down the path of creating this but it didn't work out. Too much module magic. :( Anyways, patches are welcome as I probably won't be addressing this myself anytime soon.

er... I meant to say.. "in short there is no way, currently, to disable this"

Ah I figured it out. Since background_processes.rb is using Delayed::Job not ::Delayed::Job, this solves the problem without affecting anything outside of email-spec:

module EmailSpec
  module Delayed
    class Job
      def self.work_off
        # nothing
      end
    end
  end
end

I think I'm happy with that little hack for the time being :)

I was trying to do what you were describing: have people manually require 'email_spec/background_processes' in their env.rb... but I'm also having a ton a trouble getting the module magic to work... my meta-programming skills are failing me...

To me it seems like it should be as simple as getting rid of "include EmailSpec::BackgroundProcesses::Compatibility" in deliveries.rb:68 and getting rid of "require 'email_spec/background_processes'" on email_spec.rb:8 and changing background_processes.rb to insert itself into EmailSpec::Deliveries... I tried

EmailSpec::Deliveries.class_eval do
  include EmailSpec::BackgroundProcesses::DelayedJob
end

but it doesn't seem to insert the EmailSpec::BackgroundProcesses::DelayedJob methods into the chain... oh well...

Right, I ran into the same issue. I was able to reproduce it in an irb session. Basically, mixing in modules after the fact effects method delegation differently than as if it happens inline (as presently defined). I think a redesign of how that is all working would be in order. I'm thinking more objects as strategies and less modules and method chaining. :) Glad you got an acceptable work-around for now though.