Allow gem to work without adding to Gemfile

spring itself is able to run without being added to the Gemfile, so it would be great if this gem could also be so nice. Currently, if I just add require 'spring/watcher/listen' to my ~/.spring.rb, I get this message on spring startup under Linux:

/home/ari/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/listen-3.0.6/lib/listen/adapter/linux.rb:30:in 'require': cannot load such file -- rb-inotify (LoadError)

I'm able to work around the issue by putting all of this in ~/.spring.rb, but I'm not sure why the load path order matters for those gems.

$: << Gem::Specification.find_by_name('ffi').full_require_paths.first
$: << Gem::Specification.find_by_name('rb-fsevent').full_require_paths.first
$: << Gem::Specification.find_by_name('rb-inotify').full_require_paths.first
require 'spring/watcher/listen'

spring itself is able to run without being added to the Gemfile

Yes, but that's because spring is pretty much just a wrapper for fork(). Which means: there are no dependencies here to be useful.

so it would be great if this gem could also be so nice.

Sadly, file monitoring isn't a part of Ruby's standard library. And it probably never will be. So this means either the code needed will be in other gems, or it would have to be "copied" into Listen.

Also, Listen using different backends depending on the users' filesystem. (Not just the operating system). E.g.:

rb-inotify (for inotify listening on Linux - always a dependency for convenience)
rb-fsevent (for fsevent listening on OSX - always a dependency for convenience)
wmd (for listening on Windows - needs to be added manually if used)
polling (internally implemented in Listen - doesn't need any external dependencies)

Theoretically, Listen should work in polling mode without any dependencies (which may be what you want, although performance would suffer a lot - especially by comparison on Linux where inotify is fast).

Your points about dependencies are valid, but they add extra "expert-level" steps for the largest audience here: web designers. (Rails or sass). A few months ago I spent many hours just to remove the dependency on Celluloid in Listen. (Which is why Listen 3.x was released).

Also, Listen is mostly an big fat OSX "workaround" - where reliable file monitoring requires the most gymnastics.

Actually, for Linux, what you'd want is a non-existing project called: "spring-watcher-rb-inotify".

But you'd still need those two dependencies, because: rb-inotify provides the wrapper for inotify and FFI provides the OS bindings for inotify.

So without dependencies, the best option is to use plain vanilla spring with polling.

Summary: the dependencies depend on a user's preferences - which is why Listen doesn't define them.

but I'm not sure why the load path order matters for those gems.

Probably a rbenv setup issue, because they aren't in any gemspec, unlike Listen: https://github.com/jonleighton/spring-watcher-listen/blob/master/spring-watcher-listen.gemspec#L22

and Listen's gem pulls it in as a dependency by default: https://github.com/guard/listen/blob/master/listen.gemspec#L27

Add the following before the require:

system("gem env")

to help debug what's wrong.

rails / spring-watcher-listen

Allow gem to work without adding to Gemfile #11