Bug #89536 for Moose: Some packages don't compile standalone

Tue Oct 15 16:02:36 2013 dmcbride [...] cpan.org - Ticket created

Subject:

Some packages don't compile standalone

Some packages don't compile standalone. (Why do I want to do this? To ensure that a package is fully installed.) $ perl -MMoose::Meta::TypeConstraint::Union -e 1 The 'add_attribute' method cannot be called on an immutable instance at /usr/local/lib64/perl5/5.18.1/x86_64-linux-thread-multi/Class/MOP/Class/Immutable/Trait.pm line 32. Class::MOP::Class::Immutable::Trait::_immutable_cannot_call('add_attribute') called at /usr/local/lib64/perl5/5.18.1/x86_64-linux-thread-multi/Class/MOP/Class/Immutable/Trait.pm line 47 Class::MOP::Class:::around('CODE(0x1f335d0)', 'Class::MOP::Class::Immutable::Class::MOP::Class=HASH(0x22234c0)', 'type_constraints', 'accessor', 'type_constraints', 'default', 'CODE(0x1d21b40)', 'definition_context', 'HASH(0x2784f90)', ...) called at /usr/local/lib64/perl5/5.18.1/x86_64-linux-thread-multi/Class/MOP/Method/Wrapped.pm line 162 Class::MOP::Method::Wrapped::__ANON__('Class::MOP::Class::Immutable::Class::MOP::Class=HASH(0x22234c0)', 'type_constraints', 'accessor', 'type_constraints', 'default', 'CODE(0x1d21b40)', 'definition_context', 'HASH(0x2784f90)') called at /usr/local/lib64/perl5/5.18.1/x86_64-linux-thread-multi/Class/MOP/Method/Wrapped.pm line 91 Class::MOP::Class::Immutable::Class::MOP::Class::add_attribute('Class::MOP::Class::Immutable::Class::MOP::Class=HASH(0x22234c0)', 'type_constraints', 'accessor', 'type_constraints', 'default', 'CODE(0x1d21b40)', 'definition_context', 'HASH(0x2784f90)') called at /usr/local/lib64/perl5/5.18.1/x86_64-linux-thread-multi/Moose/Meta/TypeConstraint/Union.pm line 24 require Moose/Meta/TypeConstraint/Union.pm called at -e line 0 main::BEGIN() called at /usr/local/lib64/perl5/5.18.1/x86_64-linux-thread-multi/Moose/Meta/TypeConstraint/Union.pm line 0 eval {...} called at /usr/local/lib64/perl5/5.18.1/x86_64-linux-thread-multi/Moose/Meta/TypeConstraint/Union.pm line 0 Compilation failed in require. BEGIN failed--compilation aborted.

Tue Oct 15 16:16:44 2013 ether [...] cpan.org - Correspondence added

On 2013-10-15 13:02:36, DMCBRIDE wrote: Show quoted text

> Some packages don't compile standalone. (Why do I want to do this? To > ensure that a package is fully installed.) > > $ perl -MMoose::Meta::TypeConstraint::Union -e 1

$ perl -mMoose::Util::TypeConstraints -e1 $ echo $? 0 Loading the module works fine -- just don't assume that also calling ->import with no arguments is going to work in isolation.

Tue Oct 15 16:16:44 2013 The RT System itself - Status changed from 'new' to 'open'

Tue Oct 15 16:16:44 2013 ether [...] cpan.org - Status changed from 'open' to 'resolved'

Tue Oct 15 16:18:00 2013 ether [...] cpan.org - Correspondence added

On 2013-10-15 13:16:44, ETHER wrote: Show quoted text

> On 2013-10-15 13:02:36, DMCBRIDE wrote:

> > Some packages don't compile standalone. (Why do I want to do this? To > > ensure that a package is fully installed.) > > > > $ perl -MMoose::Meta::TypeConstraint::Union -e 1

> > $ perl -mMoose::Util::TypeConstraints -e1 > $ echo $? > 0

Oops, sorry, I used the wrong module here. But still, I think this counts as "so don't move your arm like that" situation.

Tue Oct 15 16:23:35 2013 ether [...] cpan.org - Correspondence added

"Why do I want to do this? To ensure that a package is fully installed." --> this is what the Moose distribution's test suite is for -- these tests passing is both necessary and sufficient to make this determination. (If there are some things you feel could be added to the test suite, patches welcome.) :)

Tue Oct 15 18:22:41 2013 dmcbride [...] cpan.org - Correspondence added

On Tue Oct 15 16:23:35 2013, ETHER wrote: Show quoted text

> "Why do I want to do this? To ensure that a package is fully > installed." --> this is what the Moose distribution's test suite is > for -- these tests passing is both necessary and sufficient to make > this determination. > > (If there are some things you feel could be added to the test suite, > patches welcome.) :)

Not quite. I'm writing code to actually perform the install of Moose (among over 100 other modules). Another module requires M::M::TC::Union. So, to check if it's already installed, I try loading it. It fails, so I'm assuming ::Union isn't installed. And thus I'm failing. There are other ways to determine whether a module is installed, sure, but this works for almost every other module out there already. It's simple, quick, and painless. It's also fairly thorough in that it loads everything to ensure it can even compile and isn't some incomplete vestige, or that its prereqs weren't met somehow (you can probably imagine that the number of modules that incompletely specify their prereqs is a non-trivial number). Having this fail due to incomplete prereqs is generally okay - it forces me to find those prereqs and install them. The next time the build comes along, this fails, we move on, eventually hit the prereq, install that, then come back and re-try this one and it works. But not for ::Union - it just won't load. Whatever it requires to be loaded first, it doesn't ensure is actually loaded first. (I can't use "cpan" or its variants for legal reasons: I have to guarantee to my lawyer that what we're shipping is what she agreed we are legally allowed to ship. Accidentally getting a newer version of some module is strictly prohibited and could, in theory, land us in legal trouble if the license changed from one version to the next, or if a prereq involved a license that is incompatible with what we're shipping. And if, in the expected case, that doesn't happen, it'll get *me* in trouble with my lawyer, which could get me fired.) If I submit a patch for further tests, it would likely just be the above: C<use_ok("Moose::Meta::TypeConstraint::Union")> and the "oh, that fails" bit to go along with it ;) As for "no import", my general test for loading looks like this: system(qq[$TMPPERL -e 'use $module (); exit 0']); So importing isn't an issue :)

Sat Oct 19 15:43:25 2013 ether [...] cpan.org - Status changed from 'resolved' to 'open'

Sun Jun 26 09:32:36 2016 happy.barney [...] gmail.com - Ticket #115610: Ticket created

Subject:	Class::MOP::Class is not standalone package
Date:	Sun, 26 Jun 2016 15:32:25 +0200
To:	bug-Moose [...] rt.cpan.org
From:	Branislav Zahradník <happy.barney [...] gmail.com>

I would like to use its create_anon_class (in tests). Snippet: use Class::MOP::Class; my $anon = Class::MOP::Class->create_anon_class ( superclasses => [ 'Foo' ], ); throws error: Can't locate object method "initialize" via package "Class::MOP::Class" at /usr/lib/x86_64-linux-gnu/perl5/5.22/Class/MOP/Mixin.pm line 12. Same applies to Moose::Meta::Class. Although problem can be fixed by "use Class::MOP" only (Moose resp.), there remains used/required packages not referenced in code, vice versa referenced packages not used/required.

Mon Jun 27 16:38:53 2016 DROLSKY [...] cpan.org - Ticket #115610: Correspondence added

On Sun Jun 26 09:32:36 2016, happy.barney@gmail.com wrote: Show quoted text

> I would like to use its create_anon_class (in tests). > > Snippet: > > use Class::MOP::Class; > > my $anon = Class::MOP::Class->create_anon_class ( > superclasses => [ 'Foo' ], > ); > > throws error: > Can't locate object method "initialize" via package > "Class::MOP::Class" at > /usr/lib/x86_64-linux-gnu/perl5/5.22/Class/MOP/Mixin.pm line 12. > > Same applies to Moose::Meta::Class. > > Although problem can be fixed by "use Class::MOP" only (Moose resp.), > there remains used/required packages not referenced in code, vice > versa referenced packages not used/required.

I'm pretty sure this bug has been reported before and we said it wasn't going to be fixed. It's simply not feasible given the wacky bootstrapping we need to do in order to implement Class::MOP modules so that they use Class::MOP to define their own attributes, methods, etc. If you add a "use Class::MOP" to your code before "use Class::MOP::Class" it will work. I'll leave this open so no one else reports it (hopefully), but there's very little chance of this ever being fixed.

Mon Jun 27 16:38:55 2016 The RT System itself - Ticket #115610: Status changed from 'new' to 'open'

Tue Jun 28 01:05:48 2016 happy.barney [...] gmail.com - Ticket #115610: Correspondence added

Subject:	Re: [rt.cpan.org #115610] Class::MOP::Class is not standalone package
Date:	Tue, 28 Jun 2016 07:05:38 +0200
To:	bug-Moose [...] rt.cpan.org
From:	Branislav Zahradník <happy.barney [...] gmail.com>

Hi Dave, On 27 June 2016 at 22:38, Dave Rolsky via RT <bug-Moose@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=115610 > > > On Sun Jun 26 09:32:36 2016, happy.barney@gmail.com wrote:

>> I would like to use its create_anon_class (in tests). >> >> Snippet: >> >> use Class::MOP::Class; >> >> my $anon = Class::MOP::Class->create_anon_class ( >> superclasses => [ 'Foo' ], >> ); >> >> throws error: >> Can't locate object method "initialize" via package >> "Class::MOP::Class" at >> /usr/lib/x86_64-linux-gnu/perl5/5.22/Class/MOP/Mixin.pm line 12. >> >> Same applies to Moose::Meta::Class. >> >> Although problem can be fixed by "use Class::MOP" only (Moose resp.), >> there remains used/required packages not referenced in code, vice >> versa referenced packages not used/required.

> > I'm pretty sure this bug has been reported before and we said it wasn't going to be fixed. It's simply not feasible given the wacky bootstrapping we need to do in order to implement Class::MOP modules so that they use Class::MOP to define their own attributes, methods, etc. > > If you add a "use Class::MOP" to your code before "use Class::MOP::Class" it will work. > > I'll leave this open so no one else reports it (hopefully), but there's very little chance of this ever being fixed.

May I then ask to fix it in documentation at least? Simple note "full Class::MOP bootstrap is required to use Class::MOP::Class" will be enough. Or INIT/UNITCHECK block dying with meaningful error unless mentioned bootstrap is done.

Wed Jun 29 00:29:53 2016 DROLSKY [...] cpan.org - Ticket #115610: Correspondence added

On Tue Jun 28 01:05:48 2016, happy.barney@gmail.com wrote: Show quoted text

> Hi Dave, > > > On 27 June 2016 at 22:38, Dave Rolsky via RT <bug-Moose@rt.cpan.org> > wrote:

> > <URL: https://rt.cpan.org/Ticket/Display.html?id=115610 > > > > > On Sun Jun 26 09:32:36 2016, happy.barney@gmail.com wrote:

> >> I would like to use its create_anon_class (in tests). > >> > >> Snippet: > >> > >> use Class::MOP::Class; > >> > >> my $anon = Class::MOP::Class->create_anon_class ( > >> superclasses => [ 'Foo' ], > >> ); > >> > >> throws error: > >> Can't locate object method "initialize" via package > >> "Class::MOP::Class" at > >> /usr/lib/x86_64-linux-gnu/perl5/5.22/Class/MOP/Mixin.pm line 12. > >> > >> Same applies to Moose::Meta::Class. > >> > >> Although problem can be fixed by "use Class::MOP" only (Moose > >> resp.), > >> there remains used/required packages not referenced in code, vice > >> versa referenced packages not used/required.

> > > > I'm pretty sure this bug has been reported before and we said it > > wasn't going to be fixed. It's simply not feasible given the wacky > > bootstrapping we need to do in order to implement Class::MOP modules > > so that they use Class::MOP to define their own attributes, methods, > > etc. > > > > If you add a "use Class::MOP" to your code before "use > > Class::MOP::Class" it will work. > > > > I'll leave this open so no one else reports it (hopefully), but > > there's very little chance of this ever being fixed.

> > May I then ask to fix it in documentation at least? > Simple note "full Class::MOP bootstrap is required to use > Class::MOP::Class" will be enough. > Or INIT/UNITCHECK block dying with meaningful error unless mentioned > bootstrap is done.

I agree that a doc update would be good. I'd note that this problem applies to _every_ Class::MOP::* class (which all require Class::MOP), and the same applies to using Moose before most Moose::Meta::* classes. So I'm not sure exactly where the docs would go. Do we put it in every class to which this applies? I guess we could.

Sun Sep 11 15:11:45 2016 DROLSKY [...] cpan.org - Ticket #115610: Merged into ticket #89536

Sun Sep 11 15:11:45 2016 DROLSKY [...] cpan.org - Merged into ticket #89536