With the version I'm now running in EFS 3, you can do the following: EFS_PERL_DEPENDS_RUNTIME="DBI DBD-mysql GSSAPI Moose" some_script.pl
and ALL of those distros get expanded to MPRs. The metaproj defaults to perl5, and the release is auto-discovered, as the "latest available", similar to how efsdeploy does dependency expansion (it's almost, but not quite, the same code -- this is an example of where DRY does NOT apply). BTW, the code can handle BOTH "perl5/Foo" and "Foo/1.0" as well, so the old convention of passing an MPR sans the perl5 metaproj is support for backwards compatibility. I can not make it any simpler than this. Well, yes I can -- I *hate* those variable names. They are too long. Perl has: PERL5LIB PERL5OPT nice short, simple names. And I picked that monstrosity. However, since we don't have any users in EFS 3 land yet, I can still change this, and we'll just live with a block of code in sitecustomize.pl that translates the old to the new (and eventually starts whining about using the old ones, but not for a few releases). Here's the current set of env vars that EFS::Perl uses: [*] EFS_PERL_DEPENDS_NO_OBJECTS This suppressed the addition of objects to @INC, by stringifying them first, so you just get directories. This will be FAR less efficient, of course, but this is a quick way to find out if these objects are breaking things. There are several CPAN modules that we have to maintain patches for, in order to enable these objects to work correctly (Module::Install, File::ShareDir, and a couple of others). There are likely to be a few more, but it will usually only be code that directly inspects @INC. [*] EFS_PERL_DEPENDS_RUNTIME This is EFS::Perl's LD_LIBRARY_PATH, almost. This variable is read by sitecustomize.pl, and then deleted. It is saved to EFS_PERL_DEPENDS_RUNTIME_ORIG for informational purposes, but that variable is not used by EFS::PERL. IOW, this impacts ONLY the first perl invocation to see it. It will NOT be seen by anything that process forks. [*] EFS_PERL_DEPENDS_RUNTIME_GLOBAL This *IS* the same as LD_LIBRARY_PATH. This variable is read, and left in the environment, so if the perl application runs OTHER perl applications, they too will see this variable, and load those dependencies. You would use this with something calls other scripts that need the same dependencies. [*] EFS_PERL_DEBUG Turns on all the debug() diagnostics. [*] EFS_PERL_DUMP_INC There's a new END block that will print out the contents of %INC, if this var is set. This allows you to see EVERYTHING your code pulled in, and you will often be surprised at what shows up here. So.... The only variable we really have to be compatible with is EFS_PERL_DEPENDS_RUNTIME, and that's only if people are using is already in EFS 2. The no objects, debug and dump variables can change, and developers can just deal with it. I'm thinking we should switch to short vars prefixed with EFSPERL_*, for example maybe: EFSPERL_DEPENDS EFSPERL_DEPENDS_GLOBAL EFSPERL_NO_OBJECTS EFSPERL_DEBUG EFSPERL_DUMPINC I'll listen to suggestions for others.... _______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
