Sisyphus repository
Last update: 2018-04-22 18:07:29 +0400 | SRPMs: 18285 | Sign in or Sign up
en ru uk br
ALT Linux repositories
hide window
Sisyphus: 1.002005-alt1
p8: 1.002005-alt1
p7: 1.001000-alt1
t7: 1.001000-alt1

Group :: Development/Perl
Source RPM: perl-Import-Into

 Main   Changelog   Spec   Patches   Sources   Download   Gear   Bugs and FR (0/0)   Repocop 

Raw spec file

%define _unpackaged_files_terminate_build 1
#

#   - Import-Into -

#   This spec file was automatically generated by cpan2rpm [ver: 2.028]

#   (ALT Linux revision)

#   The following arguments were used:

#       '--packager=Igor Vlasenko <viy at altlinux.ru>' --url http://search.cpan.org/CPAN/authors/id/http://search.cpan.org/CPAN/authors/id/M/MS/MSTROUT/Import-Into-1.001000.tar.gz Import-Into-1.001000.tar.gz

#   For more information on cpan2rpm please visit: http://perl.arix.com/

#


%define module Import-Into
%define m_distro Import-Into
%define m_name Import-Into
%define m_author_id unknown
%define _enable_test 1

Name: perl-Import-Into
Version: 1.002005
Release: alt1

Summary: import packages into other packages

License: Artistic
Group: Development/Perl
Url: http://search.cpan.org/CPAN/authors/id/http://search.cpan.org/CPAN/authors/id/M/MS/MSTROUT/Import-Into-1.001000.tar.gz

Packager: Igor Vlasenko <viy at altlinux.ru>

BuildArch: noarch
Source: http://www.cpan.org/authors/id/H/HA/HAARG/Import-Into-%{version}.tar.gz

# Automatically added by buildreq on Thu Oct 18 2012

BuildRequires: perl-devel perl(Module/Runtime.pm)

%description
Writing exporters is a pain. Some use the Exporter manpage, some use the Sub::Exporter manpage,
some use the Moose::Exporter manpage, some use the Exporter::Declare manpage ... and some things
are pragmas.

If you want to re-export other things, you have to know which is which.
the Exporter manpage subclasses provide export_to_level, but if they overrode their
import method all bets are off. the Sub::Exporter manpage provides an into parameter
but figuring out something used it isn&#39;t trivial. Pragmas need to have
their `import&#39; method called directly since they affect the current unit of
compilation.

It&#39;s ... annoying.

However, there is an approach that actually works for all of these types.

  eval "package $target; use $thing;"

will work for anything checking caller, which is everything except pragmas.
But it doesn&#39;t work for pragmas - pragmas need:

  $thing->import;

because they&#39;re designed to affect the code currently being compiled - so
within an eval, that&#39;s the scope of the eval itself, not the module that
just `use&#39;d you - so

  sub import {
    eval "use strict;"
  }

doesn&#39;t do what you wanted, but

  sub import {
    strict->import;
  }

will apply the strict manpage to the calling file correctly.

Of course, now you have two new problems - first, that you still need to
know if something&#39;s a pragma, and second that you can't use either of
these approaches alone on something like the Moose manpage or the Moo manpage that&#39;s both
an exporter and a pragma.

So, the complete solution is:

  my $sub = eval "package $target; sub { shift->import(\@_) }";
  $sub->($thing, @import_args);

which means that import is called from the right place for pragmas to take
effect, and from the right package for caller checking to work - and so
behaves correctly for all types of exporter, for pragmas, and for hybrids.

Remembering all this, however, is excessively irritating. So I wrote a module
so I didn&#39;t have to anymore. Loading the Import::Into manpage creates a global method
`import::into&#39; which you can call on any package to import it into another
package. So now you can simply write:

  use Import::Into;

  $thing->import::into($target, @import_args);

This works because of how perl resolves method calls - a call to a simple
method name is resolved against the package of the class or object, so

  $thing->method_name(@args);

is roughly equivalent to:

  my $code_ref = $thing->can(&#39;method_name');
  $code_ref->($thing, @args);

while if a `::&#39; is found, the lookup is made relative to the package name
(i.e. everything before the last `::&#39;) so

  $thing->Package::Name::method_name(@args);

is roughly equivalent to:

  my $code_ref = Package::Name->can(&#39;method_name');
  $code_ref->($thing, @args);

So since the Import::Into manpage defines a method `into&#39; in package `import'
the syntax reliably calls that.

For more craziness of this order, have a look at the article I wrote at
http://shadow.cat/blog/matt-s-trout/madness-with-methods which covers
coderef abuse and the `${\...}&#39; syntax.

Final note: You do still need to ensure that you already loaded `$thing&#39; - if
you&#39;re receiving this from a parameter, I recommend using the Module::Runtime manpage:

  use Import::Into;
  use Module::Runtime qw(use_module);

  use_module($thing)->import::into($target, @import_args);

And that&#39;s it.

%prep
%setup -n %m_distro-%version
%build
%perl_vendor_build

%install
%perl_vendor_install

%files
%perl_vendor_privlib/Import/*

%changelog
* Sun Oct 11 2015 Igor Vlasenko <viy at altlinux.ru> 1.002005-alt1
- automated CPAN update

* Fri Jul 25 2014 Igor Vlasenko <viy at altlinux.ru> 1.002004-alt1
- automated CPAN update

* Tue May 13 2014 Igor Vlasenko <viy at altlinux.ru> 1.002002-alt1
- automated CPAN update

* Wed Mar 05 2014 Igor Vlasenko <viy at altlinux.ru> 1.002001-alt1
- automated CPAN update

* Sun Dec 22 2013 Igor Vlasenko <viy at altlinux.ru> 1.002000-alt1
- automated CPAN update

* Wed Jul 24 2013 Igor Vlasenko <viy at altlinux.ru> 1.001001-alt1
- automated CPAN update

* Thu Oct 18 2012 Igor Vlasenko <viy at altlinux.ru> 1.001000-alt1
- initial build for ALT Linux Sisyphus

 
© 2009–2018 Igor Zubkov