Pavel, I'm curious if you've started work on this and what the timeframe is. I'm hitting problems mixing AS and extlib more frequently, it seems the form builders make use of some items that differ in behavior between the two libraries. I'm happy to help out with this conversion since I have a very pressing need for it.
Thanks, Paul On Sun, Jul 11, 2010 at 8:31 PM, Paul Dlug <[email protected]> wrote: > 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.
