Pavel, I was trying to use MongoMapper with merb and was able to get it to work by changing 'require "active_support/all"' to more specific requires of just the needed extensions. I think I lucked out in that it doesn't seem to use extensions that conflict between the extlib and AS versions. Requiring all of AS is pure evil anyway but I'm sure I will hit the case shortly where there is overlap or competition between extlib + AS.
--Paul On Sat, Jul 10, 2010 at 4:14 PM, Pavel Kunc <[email protected]> wrote: > @Garry, Tony, Paul did you tried to use just the AS with the Merb? Any > information would be helpful for me if you hit some problems so I'd > know what t expect? > > @yehuda OK sounds good, thanks for the lengthly and informative > response. I appreciate that you guys brought to the Rails ecosystem > these healthy changes. > > Anyway more and more issues seems to be caused by the > incompatibilities which makes this a priority to solve for me > otherwise the Merb won't be usable for the current users which is > after all the most important. > > Pavel > > On Jun 30, 6:39 pm, Tony Mann <[email protected]> wrote: >> If the hybrid version did not take too long, then I like the idea of doing >> that for 1.2 and then ditching extlib in 1.3. If the hybrid turned out to be >> tricky or too time-consuming, then I would jump right to ditching extlib. >> >> Since DM did the hybrid thing, it probably is workable, and we can look to >> that code base for inspiration. >> >> ..tony.. >> >> >> >> On Wed, Jun 30, 2010 at 10:27 AM, Yehuda Katz <[email protected]> wrote: >> > Pavel, >> >> > As part of the general Rails 3 effort, we have put substantial time, energy >> > and effort into precisely the sort of long-term guarantees for >> > third-parties >> > that you are looking for. For Railties, those guarantees are (of course) >> > very focused on Rails applications. >> >> > For Action Pack, they are focused both on the long-term sustainability of >> > the Rails plugin ecosystem and the usage of parts of the various libraries >> > for other purposes. In particular, we have fashioned large swaths of Action >> > Dispatch to serve as a sort of an enhanced Rack library, and people have >> > been using Action View for non-web view rendering for some time. >> >> > In the case of Active Support, we have pulled out all the stops to make the >> > library work well for third parties who simply want some of the Ruby >> > enhancements. For shimming Ruby 1.8 and 1.9, we have isolated changes into >> > "active_support/ruby/shim". We have made it possible to require any part of >> > the Active Support library without knowing its dependencies on other parts >> > of the library by mandating that every file in Active Support require its >> > dependencies directly. >> >> > As of Active Support 3.0 final, you can be sure about the following going >> > forward: >> >> > * require "active_support/anything" is a public API. We will not change the >> > locations >> > of these files going forward without proper deprecation notices, the same >> > as when >> > we change anything else in Rails. >> > * All classes and modules in ActiveSupport are public APIs, and we will not >> > change >> > the semantics of the public methods on them (unless they are marked as >> > private API >> > explicitly) >> > * we will consider breaking Active Support support for non-Rails third >> > parties to be >> > equivalent to breaking public APIs used by Rails plugins. >> >> > The Rails core team is fully committed to Ruby and the Ruby ecosystem going >> > forward. We're going to have to prove it, but I am personally committed to >> > this effort, and I know that other members of the Rails core team share my >> > level of commitment. >> >> > Yehuda Katz >> > Architect | Engine Yard >> > (ph) 718.877.1325 >> >> > On Wed, Jun 30, 2010 at 3:40 AM, Pavel Kunc <[email protected]> wrote: >> >> >> Hi, >> >> >> I wanted to run small poll weather we should switch Merb to AS or not. >> >> Now it seems that voices which sounds in this google group wants to >> >> move over to the AS. At least how it looks, I'd like to hear more >> >> voices, really. >> >> >> If the Yehuda already did removed the gem dependencies on the gems >> >> such as memcache etc which was big problem for me we can start with >> >> the either hybrid or pure AS changes. Yehuda wanted to remove these >> >> dependencies really quickly at least on the EuRuKo when we had >> >> opportunity to speak about that. >> >> >> Also there is a question if we need any external library such as >> >> Extlib or ActiveSupport. The DataMapper seems to get rid of the >> >> dependency on both and use it's own inflector. Maybe the way forward. >> >> >> My only concern is, saying it out loud, that I don't believe the Rails >> >> community to care about something outside the Rails at all. I do trust >> >> Yehuda but that unfortunately doesn't mean we won't get screwed by AS >> >> in the future. >> >> >> We can make the AS support, I'd vote for the hybrid one, happen in the >> >> 1.2 (which is current head). If we decide to remove the Extlib >> >> completely I'd like to do it in the 1.3 and leave some time (1.2 - >> >> 1.3) as a transition. >> >> >> Pavel >> >> >> On Jun 30, 10:11 am, jonah honeyman <[email protected]> >> >> wrote: >> >> > On Tue, Jun 29, 2010 at 01:37:08PM -0400, Paul Dlug wrote: >> >> > > On Fri, Jun 25, 2010 at 3:41 PM, Gary Yngve <[email protected]> >> >> wrote: >> >> > > > Merb currently requires use of extlib. Unfortunately, many other >> >> > > > libraries depend on active_support because of the rails-centric ruby >> >> > > > world, so it becomes a burden on the merbist to port libraries over >> >> > > > just to get rid of the active_support dependency. Maybe it's time >> >> for >> >> > > > Merb to be "support-agnostic" and allow for active_support or >> >> extlib, >> >> > > > as DataMapper has done? (I'm ignorant to if this is happening in the >> >> > > > 1.2 branch) >> >> >> > > I'm facing the same issue, so far I've been able to patch some >> >> > > libraries to be more restrictive in their use of AS so as not to stomp >> >> > > on extlib but this is short term only. As much as I think AS is >> >> > > bloated and awful I think you may be correct that it's time to >> >> > > consider a hybrid or just a switch to it. It does look like recent >> >> > > cleanups have made it easier to be selective in the AS pieces you use >> >> > > ("require 'active_support/all'" is evil). >> >> >> > Same here :\ >> >> >> > ActiveSupport's pervasiveness in gems is really getting to be >> >> > bothersome. Especially for libs that are only using AS for one or two >> >> > things like basic string manipulation. >> >> >> > > Does anyone have an estimate on what it would take to do a hybrid vs. >> >> > > just switching to AS? Any reason to keep extlib around if merb is the >> >> > > primary (or only) user? I'd be happy to pitch in with this effort. >> >> >> > I started looking into it. It is getting more and more necessary to make >> >> > the switch to AS (IMHO, at least). While it is probably doable, merb is >> >> > so intertwined with extlib that it makes switching pretty annoying. >> >> >> > I'll be happy to help out as well. Not sure where to start exactly. I >> >> > guess removing the dependency for extlib and working from there? >> >> >> > In any event, this is a +1 for making the switch, or as Gary mentioned >> >> > allowing a choice like DM. It would be nice if PK & co. could pipe in >> >> > with whether this is realistic or not or if it is already on the agenda. >> >> >> > > --Paul >> >> >> > > -- >> >> > > 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] <merb%[email protected]>. >> >> > > For more options, visit this group athttp:// >> >> groups.google.com/group/merb?hl=en. >> >> >> > -- >> >> > -jonah >> >> >> -- >> >> 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] <merb%[email protected]>. >> >> For more options, visit this group at >> >>http://groups.google.com/group/merb?hl=en. >> >> > -- >> > 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] <merb%[email protected]>. >> > For more options, visit this group at >> >http://groups.google.com/group/merb?hl=en. > > -- > 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. > > -- 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.
