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]. For more options, visit this group at http://groups.google.com/group/merb?hl=en.
