@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.

Reply via email to