On Thu, Jan 26, 2012 at 10:39 AM, Phillip Moore <[email protected]>wrote:
> 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. > > That is quite cool. About the only thing I could think of that would make it even simpler would be to overload 'use' inside Perl core. This syntax, though, is _really simple_. ... > > 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.... > When I first looked this, I had a slight preference for the EFS_PERL_* syntax because of ease of using split(), but after I thought about it a bit, the ability to parse out 'EFS' and 'PERL' is fairly trivial either way. So either naming convention works fine for me.. Steven
_______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
