[ANN] require_all 1.0.0: A wonderfully simple way to load your code

ruby-talk
1

require_all

A wonderfully simple way to load your code.

http://github.com/tarcieri/require_all/tree/master

Tired of futzing around with require statements everywhere, littering your
code with require File.dirname(__FILE__) crap? What if you could just point
something at a big directory full of code and have everything just
automagically load regardless of the dependency structure?

Wouldn’t that be nice? Well, now you can!
require 'require_all'

You can now require_all in a multitude of different ways:
require_all *args

One of the easiest ways to require_all is to give it a glob, which will
enumerate all the matching files and load them in the proper order. For
example, to load all the Ruby files under the ‘lib’ directory, just do:
require_all 'lib/**/*.rb'

If the dependencies between the matched files are unresolvable, it will
throw the first unresolvable NameError.

Don’t want to give it a glob? Just give it a list of files:
require_all Dir.glob("blah/**/*.rb").reject { |f| stupid_file(f) }

Or if you want, just list the files directly as arguments:
require_all 'lib/a.rb', 'lib/b.rb', 'lib/c.rb', 'lib/d.rb'

It’s just that easy! Code loading shouldn’t be hard.
Methodology

I didn’t invent the approach this gem uses. It was shamelessly stolen from
Merb. Once upon a time at MountainWest RubyConf we were discussing how
horrible ActiveSupport’s dependencies.rb hijacking of const_missing and
someone described the approach Merb used to me. It was so simple and clean!
Here’s how it works:

   1. Enumerate the files in the glob
   2. Try to load all of the files. If we encounter a NameError loading a
   particular file, store that file in a “try to load it later” list.
   3. If all the files loaded, great, we’re done! If not, go through the
   “try to load it later” list again rescuing NameErrors the same way.
   4. If we walk the whole “try to load it later” list and it doesn’t shrink
   at all, we’ve encountered an unresolvable dependency. In this case,
   require_all will rethrow the first NameError it encountered.

Questions? Comments? Concerns?

You can reach the author on github or freenode: “tarcieri”

Or by email: tony@medioh.com

Got issues with require_all to report? Post ‘em here:

Github Tracker <http://github.com/tarcieri/require_all/issues>
License

MIT (see the LICENSE file for details)

···

--
Tony Arcieri
medioh.com

2

require 'facets/kernel/require_all'

The idea predates Merb. However, it's always good too see how
implementations may have improved over time.

Also, I have seen another definition of #require_all floating around
that simply loads every .rb file in a given directory. I wonder if
both conceptions of this function (glob loading and directory loading)
could be integrated into one. Eg.

  require_all 'some/path'

would do the same as

  require_all 'some/path/*.rb'

Cheers,
T.

···

On Jun 9, 5:21 am, Tony Arcieri <t...@medioh.com> wrote:

require_all

A wonderfully simple way to load your code.

http://github.com/tarcieri/require_all/tree/master

Tired of futzing around with require statements everywhere, littering your
code with require File.dirname(__FILE__) crap? What if you could just point
something at a big directory full of code and have everything just
automagically load regardless of the dependency structure?

Wouldn’t that be nice? Well, now you can!
require 'require_all'

You can now require_all in a multitude of different ways:
require_all *args

One of the easiest ways to require_all is to give it a glob, which will
enumerate all the matching files and load them in the proper order. For
example, to load all the Ruby files under the ‘lib’ directory, just do:
require_all 'lib/**/*.rb'

If the dependencies between the matched files are unresolvable, it will
throw the first unresolvable NameError.

Don’t want to give it a glob? Just give it a list of files:
require_all Dir.glob("blah/**/*.rb").reject { |f| stupid_file(f) }

Or if you want, just list the files directly as arguments:
require_all 'lib/a.rb', 'lib/b.rb', 'lib/c.rb', 'lib/d.rb'

It’s just that easy! Code loading shouldn’t be hard.
Methodology

I didn’t invent the approach this gem uses. It was shamelessly stolen from
Merb. Once upon a time at MountainWest RubyConf we were discussing how
horrible ActiveSupport’s dependencies.rb hijacking of const_missing and
someone described the approach Merb used to me. It was so simple and clean!
Here’s how it works:

1. Enumerate the files in the glob
2. Try to load all of the files. If we encounter a NameError loading a
particular file, store that file in a “try to load it later” list.
3. If all the files loaded, great, we’re done! If not, go through the
“try to load it later” list again rescuing NameErrors the same way.
4. If we walk the whole “try to load it later” list and it doesn’t shrink
at all, we’ve encountered an unresolvable dependency. In this case,
require_all will rethrow the first NameError it encountered.

Questions? Comments? Concerns?

You can reach the author on github or freenode: “tarcieri”

Or by email: t...@medioh.com

Got issues with require_all to report? Post ‘em here:

Github Tracker <http://github.com/tarcieri/require_all/issues&gt;
License

3

Trust me, Merb was not the first library to come up with Java style/globbing
import statements. I remember this being discussed a *long* time ago, and it
generally crops up from time to time on the mailing list. I'm pretty sure it
was an RCR at one point (for altering the behavior of Ruby's own require),
but I can't find it now.

But, now that I'm looking on the RAA, I can't find a library for it. So,
still a nice thing to have, thanks. :slight_smile:

Regards,

Dan

···

-----Original Message-----
From: bascule@gmail.com [mailto:bascule@gmail.com] On Behalf Of Tony
Arcieri
Sent: Tuesday, June 09, 2009 3:21 AM
To: ruby-talk ML
Subject: [ANN] require_all 1.0.0: A wonderfully simple way to load your
code

require_all

A wonderfully simple way to load your code.

http://github.com/tarcieri/require_all/tree/master

Tired of futzing around with require statements everywhere, littering
your
code with require File.dirname(__FILE__) crap? What if you could just
point
something at a big directory full of code and have everything just
automagically load regardless of the dependency structure?

Wouldn't that be nice? Well, now you can!
require 'require_all'

You can now require_all in a multitude of different ways:
require_all *args

One of the easiest ways to require_all is to give it a glob, which will
enumerate all the matching files and load them in the proper order. For
example, to load all the Ruby files under the 'lib' directory, just do:
require_all 'lib/**/*.rb'

If the dependencies between the matched files are unresolvable, it will
throw the first unresolvable NameError.

Don't want to give it a glob? Just give it a list of files:
require_all Dir.glob("blah/**/*.rb").reject { |f| stupid_file(f) }

Or if you want, just list the files directly as arguments:
require_all 'lib/a.rb', 'lib/b.rb', 'lib/c.rb', 'lib/d.rb'

It's just that easy! Code loading shouldn't be hard.
Methodology

I didn't invent the approach this gem uses. It was shamelessly stolen
from
Merb

4

Tired of futzing around with require statements everywhere, littering
your
code with require File.dirname(__FILE__) crap? What if you could just
point
something at a big directory full of code and have everything just
automagically load regardless of the dependency structure?

Wow I really like this idea.

···

--
Posted via http://www.ruby-forum.com/\.

5

  require 'facets/kernel/require_all'

Bah, should've checked facets first, but that really is the problem with
facets... it's a big kitchen sink and you never know what you're going to
find in there or not

That said, this was yanked out of a larger system and incorporates some
hacks for living along ActiveSupport and the boogiemen which lurk inside
dependencies.rb.

The idea predates Merb. However, it's always good too see how

implementations may have improved over time.

Thanks! I figure if nothing else it could have a more powerful API.

Also, I have seen another definition of #require_all floating around
that simply loads every .rb file in a given directory. I wonder if
both conceptions of this function (glob loading and directory loading)
could be integrated into one. Eg.

require_all 'some/path'

would do the same as

require_all 'some/path/*.rb'

That seems as simple as checking if the given path is a directory. Perhaps
it'd be a nice feature for 1.0.1

···

On Tue, Jun 9, 2009 at 7:06 AM, trans <transfire@gmail.com> wrote:

--
Tony Arcieri
medioh.com

6

You ask for it, you get it!

I've just released require_all 1.0.1, which in addition to all the other
functionality accepts a directory name as an argument and will glob all the
*.rb files underneath it.

Figured I'd spare the list an additional release announcement :slight_smile:

···

On Tue, Jun 9, 2009 at 7:06 AM, trans <transfire@gmail.com> wrote:

Also, I have seen another definition of #require_all floating around
that simply loads every .rb file in a given directory. I wonder if
both conceptions of this function (glob loading and directory loading)
could be integrated into one. Eg.

require_all 'some/path'

would do the same as

require_all 'some/path/*.rb'

--
Tony Arcieri
medioh.com

7

Roger Pack wrote:

Tired of futzing around with require statements everywhere, littering your
code with require File.dirname(__FILE__) crap? What if you could just point
something at a big directory full of code and have everything just
automagically load regardless of the dependency structure?

Wow I really like this idea.

Hm, what about

module Foo
   class HonkinBigResource
   end

   RESOURCE_LIST << HonkinBigResource.new
     # defer until RESOURCE_LIST defined, if necessary

   class Bar < Base
     # Base may be undefined, so defer loading of this file
   end
end

This could result in wasted time recreating a resource, duplicates on the list, etc.

Sure, it's possible to program defensively to avoid the above, but I'd rather set up a proper dependency structure with explicit requires.

Also, all uses of defined?(SomeClass) will have more or less random results, won't they?

OTOH, maybe this is like static vs. dynamic typing, and I'm just too old school to get it :wink:

···

--
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

8

Trust me, Merb was not the first library to come up with Java
style/globbing
import statements. I remember this being discussed a *long* time ago,
and it
generally crops up from time to time on the mailing list. I'm pretty
sure it
was an RCR at one point (for altering the behavior of Ruby's own
require),
but I can't find it now.

Hmm. I too wish that ruby core had something like

require_relative 'lib/a.rb'
or require_all 'lib/*.rb'
or require_all 'lib' => require_all 'lib/*.rb' or require_all
'lib/init.rb'

Thoughts?
=r

···

--
Posted via http://www.ruby-forum.com/\.

9

Hm, what about

module Foo
class HonkinBigResource
end

RESOURCE_LIST << HonkinBigResource.new
   # defer until RESOURCE_LIST defined, if necessary

class Bar < Base
   # Base may be undefined, so defer loading of this file
end
end

This could result in wasted time recreating a resource, duplicates on the
list, etc.

Yes, there are potential issues with this approach if you do that sort of
thing.

The larger issues are when you use this with something like ActiveSupport
loaded which redefines const_missing on everything. This will invoke that
const_missing callback whenever it hits a missing constant, and in
ActiveSupport its const_missing handler is an absolute nightmare.

Also, all uses of defined?(SomeClass) will have more or less random results,

won't they?

If you have code in the toplevel or a class/method body which is using
"defined?" then it is possible you will get nondeterministic results
depending on the order code is loaded in (i.e. there may be multiple
possible orderings which satisfy all dependencies), provided those constants
are getting defined in another file which you're pulling in through
require_all.

However, if you have a file which defines a bunch of constants (e.g. a
config file) you can just load that file first, then use require_all to pull
in the rest of your code.

The behavior of "defined?" inside of methods will work exactly as it always
did since that code isn't actually executed until the method is invoked.

···

On Wed, Jun 10, 2009 at 12:11 PM, Joel VanderWerf <vjoel@path.berkeley.edu>wrote:

--
Tony Arcieri
medioh.com

10

I really would like to see this in core for one reason: with a pure Ruby
solution it's incredibly difficult if not impossible to play nice with
ActiveSupport's dependencies.rb. The require_all gem contains some hacks
specific to ActiveSupport to try to play nicely, but I've still run into
cases where I have to adjust code to keep various mechanisms in
ActiveSupport's dependency loader from freaking out.

I am really curious how rails core plans to get the Merb and ActiveSupport
approaches to loading code working nicely together, or for that matter, why
Merb users using ActiveRecord as their ORM (and vicariously ActiveSupport)
don't run into "is not missing constant" errors more frequently, especially
in multithreaded programs.

···

On Wed, Jul 15, 2009 at 9:58 AM, Roger Pack <rogerpack2005@gmail.com> wrote:

Hmm. I too wish that ruby core had something like

require_relative 'lib/a.rb'
or require_all 'lib/*.rb'
or require_all 'lib' => require_all 'lib/*.rb' or require_all
'lib/init.rb'

Thoughts?

--
Tony Arcieri
medioh.com

11

Tony Arcieri wrote:

The behavior of "defined?" inside of methods will work exactly as it always
did since that code isn't actually executed until the method is invoked.

True, but sometimes methods get invoked at load time...

···

--
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

12

Tony Arcieri wrote:

Hmm. I too wish that ruby core had something like

require_relative 'lib/a.rb'
or require_all 'lib/*.rb'
or require_all 'lib' => require_all 'lib/*.rb' or require_all
'lib/init.rb'

Thoughts?

I really would like to see this in core for one reason: with a pure Ruby
solution it's incredibly difficult if not impossible to play nice with
ActiveSupport's dependencies.rb.

Yeah I wish active support would just go away. It seems unstable, even
today.

So my thought for core would be to suggest either require_relative
'lib/a.rb' or perhaps require 'directory_name' which (like Python) loads
directory_name/init.rb or what not.

My preference would be advocate require_relative, having never seemed to
miss the require 'directory_name'

Thoughts?
=r

···

On Wed, Jul 15, 2009 at 9:58 AM, Roger Pack <rogerpack2005@gmail.com> > wrote:

--
Posted via http://www.ruby-forum.com/\.