How to export several modules intu users name space to not have a use ...; use ...; use ...; with the same modules all over again

[bigj]

I want to replace the standardized beginning of perl scripts at my work that are starting with

#!/usr/bin/perl
use strict;
use warnings;

use DBI;
use Config::IniFiles;
use IO::File;
use utf8; # Skript ist UTF8-codiert
use encoding 'utf8'; # Strings in UTF8
binmode STDOUT, ':utf8'; # Ausgaben in UTF8
use POSIX qw/strftime/;

$ENV{ORACLE_HOME}="/opt/oracle/oracle/product/10.2.0/db_1";
$ENV{NLS_LANG}="GERMAN_GERMANY.UTF8"; # Datenbank ist UTF8

with something easier like

#!/usr/bin/perl
use MyFirma::Standard;

# and now I want to use and have everything like above

I know, it should be done with an exporter module, but I don't want just to import some subs but instead load the modules into namespace of the caller. Like Modern::Perl imports use strict; use warnings; use feature ...; into the callers package. In addition it should be easy to understand what is done (so I'd prefer not to hack around with mro::caller-stuff or different), just like

package MyFirma::Standard;

use GreatExporter => 
   {'use strict',
    'use warnings',
    'use DBI',
    ...
    and so on}

I think, I have already seen a module doing this, but I don't remember and I'm stuck finding the right words to search, so I hope you can help me here

[Corion]

You could look at Toolkit, which purports to eliminate company-specific boilerplate.

Personally, I'm not too happy with hiding "boilerplate" away, but if you have a strong company policy, using something like Toolkit might make it easier to do the right thing for everybody by implicitly loading the modules.

sitecustomize.pl is close, but it is run in its own scope so use strict; would not be enabled by this. Maybe consider adapting what common::sense does to your own needs? common::sense does its thing via XS, which is likely too unwieldly for your needs.

Modern::Perl does the following:

sub import
{
    my ($class, $date) = @_;
    $date = $wanted_date unless defined $date;

    my $feature_tag    = validate_date( $date );
    undef $wanted_date;

    warnings->import;
    strict->import;
    feature->import( $feature_tag );
    mro::set_mro( scalar caller(), 'c3' );
}

... and most likely, you could write Modern::Perl::MyCompany, which does the same, except with the modules you want, like by adding:

POSIX->import( 'strftime' );

[bigj]

Yep, Toolkit was the module I remembered. Thanks to pointing me to.

Personally, I'm not too happy with hiding "boilerplate" away, but if you have a strong company policy, using something like Toolkit might make it easier to do the right thing for everybody by implicitly loading the modules.

Me not also, I want to have an easy way to write quick and dirty one liners or 4 liners for simple stuff :-) Firm policy is putting it inside as posted and for production code running at live systems, I'd enhance it also (allthough I need good examples of how much you can shorten source code to fight vs copy+paste culture :-))

[RonW]

Personally, I'm not too happy with hiding "boilerplate" away, but if you have a strong company policy, using something like Toolkit might make it easier to do the right thing for everybody by implicitly loading the modules.

Where I work, the company policy for C/C++ projects is to use #include "standard.h" where standard.h contains a series of #includes and definitions we are required to use. (We are allowed to modify the project specific standard.h to fit project needs.) The rational behind this is to provide a single file (in each project) for these items to be edited, thus reducing the opportunity for introducing inconsistencies and other errors into the code.

Doing similar with Perl (and whatever other languages used in the company) would be consistent with the spirit of company policy for C/C++ projects. (All of the production software in our products is written in C/C++. For "in house" tools, the language used is left to the creator of the tool. Perl, LabView and CAPL are most common for engineering tools; VB macros for "office tools").

[Anonymous Monk]

I copy/paste, you pick the winner :)

Import::Into, ex::override ,Override the open builtin globally.. redux, Re: Selectively importing warnings (works), Re: how to make lexical pragma global, hints ( pl_hints $^H %^H ), taint::all (package taintall)

and some of these

perl5, perl5::ingy
ToolSet
Syntax::Collector
Toolkit
rig
see perlrun#PERL5OPT , PERLLIB, PERL5LIB
sitecustomize under perlrun#* f*
how to make lexical pragma global, hints ( pl_hints $^H %^H ), taint::all, Re: batch 'use' possible? (perl5.pm Toolset.pm, Syntax::Collector , Toolkit.pm, rig.pm, sitecustomize.pl, PERL5OPT )( load multiple commonly-used favorite modules in a single import expression )

export into / Import::Into

 

:D

[Discipulus]

i think it should works as expected: if you use A that uses B, C and D you have imported B, C and D in the namespaces. Also the code in A is executed so i think you can modify %ENV too. You tried the simple solution?

L*

[bigj]

Sometimes it is too easy :-o It imports the modules like DBI, but it doesn't look like the strict and warnings pragmas are imported also. Update: Also POSIX::strftime doesn't get imported, just only into the module package MyFirma::Standard

[Discipulus]

ok, never realized all subtitlies (quibbles?) of using.. and in the import of Modern::Perl there is something i dont understand but i can replicate.
While i suggest following wiser adivice you can play with:

package FirmaTest {
  print "welcome to FirmaTest\n";
  sub import
  {
    use feature ();
    feature->import ('say');
  }
  use strict;    #strictures are imported
                 # while warnings are not
  #use warnings; seems not enough..
  $^W=1;         # but setting $^W seems ok!
  
  $ENV{'FirmaTest'} = 1;#it works
  
  use POSIX qw (strftime);
}

1;

It seems to do the right think you want (notice the windows quotation..):

perl -MFirmaTest -e " print qq(warnings: $^W\n); print qq(ENV: $ENV{'F
+irmaTest'}\n); say qw(saying: aa)
 my $str = POSIX::strftime( '%B %d, %Y',0, 0, 0, 12, 11, 115, 2 );say 
+qq(POSIX::strftime: $str)  "


#output:
welcome to FirmaTest
warnings: 1
ENV: 1
saying:aa
POSIX::strftime: dicembre 12, 2015

HtH
L*

[vkon]

use strict; is lexical-scope-wise, it is specially designed to behave this way, so you can write

use strict;
....
{
  no strict;
  ....
}
# and here 'use strict' is in effect;

this is why

[sundialsvc4]

I would be reluctant to change anything, most-especially about a large number of modules that are now known to be working, and most-especially on your own volition e.g. just driven by some sense of aesthetics.   Perl, AFAIK, does not have an #include facility.   In any case, you are not only making a pervasive source-code change to many modules, but you are now coupling them one to another.   Now, not only is the source-code instantly available to be seen, but identical code has been textually bound to all of them such that it can no longer be individually changed in any one of them.   By whose authority was such a change made or contemplated?

I counsel that you should not make a change to a source-code file which does not have direct and necessary relevance to the problem being fixed and/or the feature being introduced by the associated work-order ticket.   Did the change-review committee at your place of business create an order to make such a change and then give it to you?   (I’m serious.)   If they did not, then I would meekly continue to write my code exactly as it has always been written, “easier” or not.

[Anonymous Monk]

Perl, AFAIK, does not have an #include facility.

Shirley, you can't be serious. do, require, use, eval.

[morgon]

Shirley,

Have you now resolved to talk to sundialsvc4 like Dr Cox does to J.D. or is it just a typo?

And if one wanted an #include facility in Perl that actually does the exact same thing as #include and is even used as #include one could use Filter::cpp.