So I got a few minutes to look into this while waiting on tests for another
ticket to finish. The behaviour we're expecting for
Module#const_defined?(name) is now provided by
Module#const_defined?(name,false). Module#const_defined?(name,true), which
is the default if you only pass two arguments, is does something along the
lines of Ancestors.any? { |m| m.const_defined? name }.
Ideally, we should just add a false to all our calls to const_defined?, but
in 1.8.x it only takes one parameter, not two (way to be backwards
compatible guys). Our best bet may be to add the false on all the calls and
then monkey patch something like:
* module Module
alias_method :mri_const_defined?, :const_defined?
def const_defined?(name,include_ancestors=true)
fail "Not on 1.9 yet!" if include_ancestors
const_defined?
end
end if Module.method(:const_defined?).arity == 1
*
so that it produces the expect results and forces our code to be forward
compatible. (Note that this is a hand-drawn sketch of code, not something
that's ever even been typed into irb.)
-- Markus
On Thu, Nov 5, 2009 at 12:11 AM, Al Hoang <[email protected]> wrote:
>
> On Nov 4, 8:27 pm, Markus Roberts <[email protected]> wrote:
> >
> > So if I'm not mistaken the "--debug --verbose --trace" aspect is
> incidental?
>
> Yes this is correct. I was running puppetd with those options to try
> to isolate the problem
> as much as possible.
>
> >
> > 1.9.x does change how constants are found but I suspect that a less ad
> hoc
> > solution is needed. Note that I don't have one to offer at the moment,
> just
> > a feeling that forcing specific class references to be absolute is asking
> > for maintenance problems.
>
> Understood. I am not quite satisfied with the way my changeset
> 'fixes' the problem
> so if anyone has ideas on a cleaner solution I'd be happy to hear
> better suggestions.
>
> Although, I am quite happy that puppet at least runs on 1.9.x without
> blowing
> up with my changeset :-)
>
> But just as a point of reference, I noticed some interesting
> changesets going
> into the Rails codebase that seem to be dealing with similar issues:
>
>
> http://github.com/rails/rails/commit/52e2bbd5c004f22b2affeec0fc03f1f9ca8c2a24
>
> http://github.com/rails/rails/commit/0ff8f81adcf1e025a34d4a50ea1db39384a00e0b
>
> http://github.com/rails/rails/commit/425a02cecea188f502ad8f137271d1b90b9c7558
>
> >
> > I'll add it to my list of things to look into, and would be glad to hear
> of
> > anything else you turn up along these lines (thanks, by the way, for
> kicking
> > this off).
>
> These changesets let me at least run puppet without blowing up in
> strange areas. I'll continue testing puppet on Ruby 1.9.x with my
> fork and see
> what else turns up.
>
> Cheers,
> Alain
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Developers" 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/puppet-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
