I previously proposed unshift_path. Does that work for you? -- Yehuda On Tue, Nov 18, 2008 at 3:08 PM, Liam Morley <[EMAIL PROTECTED]> wrote:
> > I think I'm late to the party, but I was the one who logged the bug > with the current set up <http://merb.lighthouseapp.com/projects/7433- > merb/tickets/1010<http://merb.lighthouseapp.com/projects/7433-merb/tickets/1010>>, > I thought I might weigh in. > > The way things are right now is that, by doing nothing, lib is not > loaded at all, but if you choose to *explicitly* load lib into your > path by using push_path, it's loaded after the rest of your code, > hence your code can't reference it unless you manually require it. I > can't really see how this is the best approach. > > Because push_path takes a path argument (the default is lib/**/*.rb > but you can set it differently), you can set different rules for how > you want to import your code. You could, for example, autoload lib/ > *.rb, and anything in a subdirectory would not be loaded. There are a > lot of options here, and none of them are magic due to the fact that > you need to explicitly invoke push_path. > > I think everybody wants less magic, which is why I'm thrilled about > this explicit invocation. But push_path that my app can't make use of > seems impotent to me. I'm all for including :lib before the code > in :app, but continuing to have the default :lib path be nil, and > avoid autoloading. (I'm not sure if that's what you guys were > suggesting- my suggestion is not pro-autoloading, but nor is it pro- > status quo.) > > Liam > > > On Nov 17, 1:47 am, "Matt Aimonetti" <[EMAIL PROTECTED]> wrote: > > Do I understand that we have an agreement and lib code shouldn't be auto > > loaded? > > (I'm sorry I didn't read every single msg in the thread) > > > > -Matt > > > > On Mon, Nov 17, 2008 at 1:43 AM, Michael Klishin < > > > > [EMAIL PROTECTED]> wrote: > > > > > 2008/11/17 Julian Leviston <[EMAIL PROTECTED]>: > > > > > > I reckon put the option in config. > > > > Possible? > > > > > It is sure possible technically but if you ask me right now what is > > > the ugliest piece of code in merb core that > > > I hate, I'd say all the > > > dependencies-to-framework-layout-to-boot-sequence parts. Don't get me > > > wrong, they do not > > > require you sitting for *hours* to understand and way better thought > > > out that some other dependencies code that I've seen. > > > But it's very tricky thing to modify, and it struggles from what I > > > call "Dell vs. Apple problem": trying to support a lot of 3rd party > > > code does make things complex, and bundling everything in a single > > > monolithic package would make certain pieces of > > > the framework much simpler (but it's never gonna happen to merb). > > > > > I personally would drop almost any feature just to not complicate it > > > further. If we can explain people how to approach this autoloading > > > behavior, > > > it shouldn't be much of a problem. > > > -- > > > MK > > > -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "merb" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/merb?hl=en -~----------~----~----~----~------~----~------~--~---
