Re: RFC 78 (v1) Improved Module Versioning And Searching
2000-08-09-21:00:31 Chaim Frenkel: Making a module local to the using package, might have interesting properties. [...] The only breakage that I see, is having some way of globally setting a variable. For example, turning on debugging for all uses. (FTP::Debug I find quite popular.) Can anyone see any other breakage? Not other breakage, but another example of the same exact class of breakage. In RFC 70 I proposed some (hopefully minor) language cleanups to make it possible to have Fatal.pm actually work the way people want it. If it worked, then Fatal.pm would be getting some categories it supported, e.g. "use Fatal qw(:io);". I then suggested that the invoked categories could be posted into a testable variable, in case other module authors wished to cooperate with this protocol. If the only real problem that can be found with making module use package-local is in these few option-flag type variables, perhaps they could be handled differently. E.g. suppose normal package variables end up being local to the package that "use"-es the package, and when a package actually wants to make a genuine global for all users of the package, it explicitly tucks it into a variable whose name starts with main::. E.g. let Net/FTP.pm post its debug flag into $main::Net::FTP::Debug, and the list of exception classes requested of Fatal.pm could be posted into @main::Fatal. The next natural thought seems to be that the module creating such a global should check and see if it's being used by main, and only post into the global if so, otherwise let its option[s] be user-local. Can import() use caller() this way? That would allow a module author to e.g. code their module using Fatal, without affecting anything outside their module, while allowing main's invocation (if any) of Fatal to offer guidance to other modules that chose to try and honor it. -Bennett PGP signature
Re: RFC 78 (v1) Improved Module Versioning And Searching
2000-08-09-17:33:25 Steve Simmons:
If that's the intent, then yes, author name must become part of the
package identifier. Rather than change the meaning of "ref $object"
unexpectedly, I'd add one or more alternate forms of ref. Off the
top of the head, something like
( $version, $class ) = vref $object; # ref with version
( $author, $class ) = aref $object; # ref with author
( $version, $author, $class ) = fref $object; # get all
Rather than proliferating the number of keywords eaten with all
these *ref varients, this sounds like a useful place for returning
an object with a default stringification of the class:
$class = ref $object; # when you use $class as a string,
# or 2nd arg to bless()
$version = $class-{VERSION};
$author = $class-{AUTHOR};
Ref RFC 37, RFC 73.
-Bennett
PGP signature
Re: RFC 78 (v1) Improved Module Versioning And Searching
On Wed, Aug 09, 2000 at 05:53:44PM -0400, Ted Ashton wrote: I'll take that as my cue ;-). Ah, nothing like a man who knows when to pick up his cues. *shudder* This whole business is getting pretty scary . . . [[ discussion of ugly implicatations elided ]] The short answer is that (assuming I understand Larry's statement) he'd like these issues addressed. If the resulting `best' answer is so complex and so ugly that he decides it's a bad idea, that's fine -- but (if I recall correctly) tcl has addressed this problem and come up with workable solutions. I'm not intimately familiar with them, but will get so.
Re: RFC 78 (v1) Improved Module Versioning And Searching
Thus it was written in the epistle of Steve Simmons, On Wed, Aug 09, 2000 at 05:53:44PM -0400, Ted Ashton wrote: I'll take that as my cue ;-). Ah, nothing like a man who knows when to pick up his cues. :-) *shudder* This whole business is getting pretty scary . . . [[ discussion of ugly implicatations elided ]] The short answer is that (assuming I understand Larry's statement) he'd like these issues addressed. If the resulting `best' answer is so complex and so ugly that he decides it's a bad idea, that's fine -- but (if I recall correctly) tcl has addressed this problem and come up with workable solutions. I'm not intimately familiar with them, but will get so. Understood. After a bit of reflection on it, I got to wondering, what if it 1) Searched all of @INC for the most recent module which fits within the constraints given (version range numbers, at least). 2) Loaded the module globally (as it does now) *unless* told not to. Thus, if a module wanted to use Foo private; then it could. As far as the author business goes, is it becoming unwieldy to have portions of the namespace assigned to specific authors? That is, Devel::SmallProf is mine (as per committee decision) and others wanting to write small profilers can have TinyProf, MicroProf and so forth. I really think that multiple versions of a module are a fairly natural thing, but that modules with the same name by different folks are bound to cause confusion, much beyond the actual running of programs. PerlUserA: I keep having this problem with the Foo::Bar module. It won't grok blargs as it ought. PerlUserB: You must be doing something wrong. It works fine for me. *three day conversation ensues* PerlUserB: I give up. I don't know what you're doing wrong. Why don't you write to Tom and ask him. PerlUserA: Tom, why Tom? PerlUserB: Because he wrote the module. PerlUserA: No he didn't. Ilya wrote it. Ted -- Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University == It is not knowledge, but the act of learning, not possession but the act of getting there, which grants the greatest enjoyment. When I have clarified and exhausted a subject, then I turn away from it, in order to go into darkness again; the never-satisfied man is so strange if he has completed a structure, then it is not in order to dwell in it peacefully, but in order to begin another. I imagine the world conqueror must feel thus, who, after one kingdom is scarcely conquered, stretches out his arms for others. -- Gauss, Karl Friedrich (1777-1855) == Deep thoughts to be found at http://www.southern.edu/~ashted
Re: RFC 78 (v1) Improved Module Versioning And Searching
On Thu, Aug 10, 2000 at 11:01:39AM -0400, Bennett Todd wrote: Rather than proliferating the number of keywords eaten with all these *ref varients, this sounds like a useful place for returning an object with a default stringification of the class: . . . Ref RFC 37, RFC 73. I have no problem with this or any other solution that gets the data back. I'll add a comment to RFC78 that should those RFCs prevail, we'll follow them. For the record, I prefer hashes for that sort of thing too. But perl has traditionally done ordered list returns, and I followed in that vein.
Re: RFC 78 (v1) Improved Module Versioning And Searching
At 10:43 AM 8/10/00 -0400, Bennett Todd wrote:
2000-08-09-21:00:31 Chaim Frenkel:
Making a module local to the using package, might have interesting
properties. [...]
The only breakage that I see, is having some way of globally setting
a variable. For example, turning on debugging for all uses. (FTP::Debug
I find quite popular.)
Can anyone see any other breakage?
Not other breakage, but another example of the same exact class
of breakage. In RFC 70 I proposed some (hopefully minor) language
cleanups to make it possible to have Fatal.pm actually work the
way people want it. If it worked, then Fatal.pm would be getting
some categories it supported, e.g. "use Fatal qw(:io);". I then
suggested that the invoked categories could be posted into a
testable variable, in case other module authors wished to cooperate
with this protocol.
Why not, then, introduce non-fatal errors and a new keyword to throw them?
Something like quit(), which could take an error class, an error identifier
(a number or short string or something) and a message. It'd work like a
bare return, but also stick something in $@, and could be trappable. (Quit
with one parameter would default the class to generic, and the identifier
to unknown)
This way, when something needs to bail with a non-fatal error it could:
quit('io', 'READERROR', "Unable to read from file $foo");
and the code calling the sub could, if it wanted, could do a plain:
$foo = some_sub($file);
or:
{
use fatal;
eval {
$foo = some_sub($file);
};
if ($@) {
if ($@-nonfatal) {
# handle non-fatal errors
}
}
}
or something like that.
*) Define a set of c
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
RE: RFC 78 (v1) Improved Module Versioning And Searching
-Original Message- From: Steve Simmons [mailto:[EMAIL PROTECTED]] For the record, I prefer hashes for that sort of thing too. But perl has traditionally done ordered list returns, and I followed in that vein. Perhaps Damian's want() (RFC 21) can be used to allow allow either return type? Assuming that's adopted, of course. -Corwin
Re: RFC 78 (v1) Improved Module Versioning And Searching
At 05:46 PM 8/10/00 +0100, Graham Barr wrote: On Thu, Aug 10, 2000 at 12:28:05PM -0400, Dan Sugalski wrote: No, it wouldn't, really. We could make "use fatal;" scoped, so that the quit op (or whatever it is) only jumps through all its hoops if the pragma's in effect. If its not, then quit(foo, bar, baz) does a bare return and that's it. You'd have the overhead of checking a flag when actually quitting with an error, but that adds a very small amount of overhead to an exceptional case. Why not make that flag avaliable instead of having a new op ? The user can then write $^fatal ? die : return; Sure, that works. Whatever keyword throws the non-fatal error might just be a perl sub that does exactly that, at least to start. (Maybe always, who knows) Hm, although people may start to mis-use the flag. What, people misuse core functionality? I can't picture *that* happening. It's so unperlish... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 78 (v1) Improved Module Versioning And Searching
Perhaps Damian's want() (RFC 21) can be used to allow allow either return type? Yes indeed. Assuming that's adopted, of course. Sure looks to me like a good idea; I hope it does.
Re: RFC 78 (v1) Improved Module Versioning And Searching
I'd put it into
Perl::Option{__Package__}
There was some talk about making Perl:: special. So that might be the one
and only truely global space.
Hmm, that wouldn't work with multiple versions without cooperation.
Alternatively, we could treat a set
Perl::Option{FTP::Net}-Debug = 255;
as a method call, and have the package determine it's caller.
chaim
"BT" == Bennett Todd [EMAIL PROTECTED] writes:
BT If the only real problem that can be found with making module use
BT package-local is in these few option-flag type variables, perhaps
BT they could be handled differently. E.g. suppose normal package
BT variables end up being local to the package that "use"-es the
BT package, and when a package actually wants to make a genuine global
BT for all users of the package, it explicitly tucks it into a variable
BT whose name starts with main::. E.g. let Net/FTP.pm post its debug
BT flag into $main::Net::FTP::Debug, and the list of exception classes
BT requested of Fatal.pm could be posted into @main::Fatal.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 78 (v1) Improved Module Versioning And Searching
On Thu, Aug 10, 2000 at 10:43:02AM -0400, Bennett Todd wrote: If the only real problem that can be found with making module use package-local is in these few option-flag type variables, perhaps they could be handled differently. E.g. suppose normal package variables end up being local to the package that "use"-es the package, and when a package actually wants to make a genuine global for all users of the package, it explicitly tucks it into a variable whose name starts with main::. E.g. let Net/FTP.pm post its debug flag into $main::Net::FTP::Debug, and the list of exception classes requested of Fatal.pm could be posted into @main::Fatal. And the difference is ? $ perl -e 'warn \$main::fred::x," ",\$fred::x' SCALAR(0x80dc254) SCALAR(0x80dc254) at -e line 1. Graham.
Re: RFC 78 (v1) Improved Module Versioning And Searching
2000-08-10-17:36:41 Graham Barr: And the difference is ? $ perl -e 'warn \$main::fred::x," ",\$fred::x' SCALAR(0x80dc254) SCALAR(0x80dc254) at -e line 1. Today there's no difference. If the proposal under discussion were to pass, and packages' namespaces were to become local to the namespace where the "use" occurred, then perhaps main::whatever could be a common, stable, global that they could use for these rare variables that really need to be common from multiple invokers. -Bennett PGP signature
Re: RFC 78 (v1) Improved Module Versioning And Searching
At 10:44 AM 8/9/00 -0700, Larry Wall wrote: [EMAIL PROTECTED] writes: : Note that it may not be possible to satisfy conflicting requests. If : module CA and module CB demand two different versions of the same : module CC, the compiler should halt and state the module conflicts. Pardon me for sniping at a great RFC, but I already promised the CPAN workers that I'd make that last statement false. There's no reason in principle why two modules shouldn't be allowed to have their own view of reality. Just because you write Foo::bar in your module doesn't mean that Perl can't know which version of Foo:: you mean. Does that mean, then, that when module A does a "$C::bar = 1" it affects a different package namespace than module B doing a "$C::bar = 2"? And does it also extend to things like this: package A; use C 1.2; package B; use C 1.4; where two packages in the same file use different versions of module C and get them? Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 78 (v1) Improved Module Versioning And Searching
At 11:11 AM 8/9/00 -0700, Larry Wall wrote: Dan Sugalski writes: : Does that mean, then, that when module A does a "$C::bar = 1" it affects a : different package namespace than module B doing a "$C::bar = 2"? Presumably. H. That brings up some issues of ambiguity, then. If you use C in package A, and also in package B, which do you see when you're in main and access $C::bar? : And does it also extend to things like this: : : package A; : use C 1.2; : package B; : use C 1.4; : : where two packages in the same file use different versions of module C and : get them? I expect that could also be made to work, provided the semantics of importation remain package-scoped and don't become lexically scoped. Sure. They'd have to be, otherwise packages split across different files would get a rather bizarre view of the world. This sort of means we'll need some sort of two-level stash, one per-package and one global. (Unless you're outlawing symbolic references... :) To me, it really just means that the *real* name of the package includes the implementation (author?) and version, but that when you say use C; you're just choosing to wildcard both the implementation and version. This view says that we probably ought to figure out how to encode the implementation and version syntactically as part of the package name, rather than as a 3rd argument to use. Yup. I can see the build procedures needing to know this too, since we'll probably need to give modules with shared libraries unique names. Some platforms (OS/2 and VMS, at least) will need that, as they get cranky if you try and load shareables with the same base filename. Think about the long names of fonts for an example of how far this can be taken. Would this be "Taken to its logical and sensible conclusion" or "Taken as far as it can possibly go, though it you turn around and look *really* hard with binoculars you can see where you crossed the line, way back there by the horizon"? Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 78 (v1) Improved Module Versioning And Searching
On Wed, Aug 09, 2000 at 10:44:03AM -0700, Larry Wall wrote:
: Note that it may not be possible to satisfy conflicting requests. If
: module CA and module CB demand two different versions of the same
: module CC, the compiler should halt and state the module conflicts.
Pardon me for sniping at a great RFC . . .
No problem, I don't feel sniped at.
. . . but I already promised the CPAN
workers that I'd make that last statement false. There's no reason in
principle why two modules shouldn't be allowed to have their own view
of reality. Just because you write Foo::bar in your module doesn't mean
that Perl can't know which version of Foo:: you mean.
Near the end of the RFC this topic does come up; see it directly at
http://www.nnaf.net/~scs/Perl6/RFC78.html#Alternative_Idea_Module_Versio.
That section was much longer in my unreleased drafts, but did include
some discussion on disambiguation when multiple versions of the same
module are loaded. In the RFC I wrote off this idea with ``In This Way
Lies Madness, but perl has done stranger things.''
If we want to open that can of worms I'm willing to pitch in. I'll even
continue on with the task of maintaining the RFC, or starting another
if appropriate. But I'd barely started thinking about this issue with
respect to perl until a couple of days ago, so folks who are much more up
to speed on language/inheritence/etc are going to have to carry the load.
Turning back to some specific comments made by Larry and by Dan Sugalski:
LW The larger view of it is how to support package aliasing. A package
LW name is essentially the name of a public interface. Suppose you
LW have one interface, but two or more different implementations of
LW that interface by different people. Each might have their own
LW version sequence.
Package aliasing should certianly be allowed; the RFC already contains
a suggestion for it:
use foo 3.0 as foo_old;
use foo =3.0. as foo;
use foo 3.0. as new_foo;
Using the alias gets you what you need.
Your comment above implies that CPAN may (will be allowed to) contain
modules of the same name and same version by different authors. Is this
correct? If so (shudder), what happens currently when both are installed?
I presume one simply overwrites some or all of the other.
If that's the intent, then yes, author name must become part of the
package identifier. Rather than change the meaning of "ref $object"
unexpectedly, I'd add one or more alternate forms of ref. Off the
top of the head, something like
( $version, $class ) = vref $object; # ref with version
$version = vref $object; # scalar context gets version
( $author, $class ) = aref $object; # ref with author
$author = aref $object; # scalar context gets author
( $version, $author, $class ) = fref $object; # get all
# Scalar context gets a string suitable for select the
# exact object in use
$fq_name = fref $object;
if ( $fqname eq fref $other_object )...
LW Another question is whether the two different versions of the "same"
LW module are going to stomp on each other? (Not in package space, since
LW the packages are distinguished internally, but how about in the
LW filesystem?)
If we include author name along with the version number in the file system
namespace (gawd, I can't believe I just wrote that), then clobbering
won't happen. IMHO this feature is no more difficult to add to the
install process than adding version numbers; it implies tho that we
need a $AUTHOR var in all modules and to allow for it in module `version'
specifications. Again, off the top of the head, we could allow a string
(any string that would not be confused with a version number) to indicate
the author:
use foo CONWAY =1.3 as foo_good;
use foo GATES 1.3 as foo_bad;
use foo * as foo_desperate;
As long as there's no author names `as', we're cool. I suspect the
proposed syntax in the RFC could be extended to handle this unambiguously
both for run/compile-time module naming and for installation, but need
to think it thru.
DS Does that mean, then, that when module A does a "$C::bar = 1" it
DS affects a different package namespace than module B doing a
DS "$C::bar = 2"?
LW Presumably.
Yes, that's how I'd see it too. Which creates a real problem for
modules which do things like
package foo;
{
my $hidden_var;
sub new {
if ( $hidden_var ) {
do x;
} else {
do y;
}
}
}
Now there are two copies of $hidden_var while the module clearly expects
only one. Either this kind of construction will have to be avoided,
or some mechanism developed which allows multiple version of a module
to somehow share important data which is otherwise hidden by such tricks.
IMHO, module authors should be able to forbid multi-loads across
sufficiently different versions of the module (ie, all
Re: RFC 78 (v1) Improved Module Versioning And Searching
At 01:50 PM 8/9/00 -0700, Larry Wall wrote: Dan Sugalski writes: : At 11:11 AM 8/9/00 -0700, Larry Wall wrote: : Dan Sugalski writes: : : Does that mean, then, that when module A does a "$C::bar = 1" it affects a : : different package namespace than module B doing a "$C::bar = 2"? : : Presumably. : : H. That brings up some issues of ambiguity, then. If you use C in : package A, and also in package B, which do you see when you're in main and : access $C::bar? I dunno. I don't imagine the situation will arise that often. It'll happen at least once. I suppose we could go insane and make packages loaded in through modules completely invisible to all but the use-ing package, so in this case main wouldn't even know there was a C loaded, and if it tries to mess with things in the C package it gets its own empty stash to deal with. (Which all other packages that didn't use one version of the module or another get) I suppose that's a fancy way of saying namespaces created by used modules are private to the package using them. (Though that still leaves the issue of what happens when package B uses something from package C which wasn't created on the use, but then I'd probably just say "you get your version of C. Nyah!") Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 78 (v1) Improved Module Versioning And Searching
Thus it was written in the epistle of Steve Simmons, . . . but I already promised the CPAN workers that I'd make that last statement false. There's no reason in principle why two modules shouldn't be allowed to have their own view of reality. Just because you write Foo::bar in your module doesn't mean that Perl can't know which version of Foo:: you mean. OK, let's let someone else get into the conversation. I'll take that as my cue ;-). DS . . . If you use C in package A, and also in package B, which do you DS see when you're in main and access $C::bar? LW I dunno. I don't imagine the situation will arise that often. It may not happen often, but once is enough. IMHO the answer is `in load order' unless the programmer does something explicit to resolve the issue. *shudder* This whole business is getting pretty scary. Best that I can tell, what y'all are saying is that if A and B happen to both load the same version of C, then A can say $C::flag = 1 and B can see that, but if they load differing versions, then they can't (as there are two copies of $C::flag). Oi! If you are going to split it up in that fashion, I would think that you would have to go all the way. No matter what version is available, every load of a package from another package is private to that package. A has it's mirage of C and B has it's mirage of C, even if they loaded the same version, and main has no access to either. I happen to have a profiler out there which uses the DB package. What happens if someone loads SmallProf and DProf and the perl debugger all at once? Ted -- Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University == Mathematics is not only real, but it is the only reality. That is that entire universe is made of matter, obviously. And matter is made of particles. It's made of electrons and neutrons and protons. So the entire universe is made out of particles. Now what are the particles made out of? They're not made out of anything. The only thing you can say about the reality of an electron is to cite its mathematical properties. So there's a sense in which matter has completely dissolved and what is left is just a mathematical structure. -- Gardner, Martin == Deep thoughts to be found at http://www.southern.edu/~ashted
Re: RFC 78 (v1) Improved Module Versioning And Searching
On 9 Aug 2000 15:03:40 -, Perl6 RFC Librarian wrote: Improved Module Versioning And Searching [About loading different versions of a module at the same time] The whole thing sounds whacky to me. I don't really mind that @INC is searched for the most recent version of a module, but otherwise, my solution would be simple: authors that don't provide complete backward compatibility with older versions of the same module, safe the bugs, and safe beta versions, should be kicked of CPAN. ;-) (I wouldn't dare...) -- Bart.
Re: RFC 78 (v1) Improved Module Versioning And Searching
Let's not throw this out completely. Let's explore the possiblities. Making a module local to the using package, might have interesting properties. The only items of interest are the globals. And by making them visible (or a version visible) to the use-ing module, two modules can get different behaviours without stomping on each other. All the isolation that we're developing for threads would help this out. So the used package's globals can be lexically scoped in the user. The only breakage that I see, is having some way of globally setting a variable. For example, turning on debugging for all uses. (FTP::Debug I find quite popular.) Can anyone see any other breakage? chaim "DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS It'll happen at least once. DS I suppose we could go insane and make packages loaded in through modules DS completely invisible to all but the use-ing package, so in this case main DS wouldn't even know there was a C loaded, and if it tries to mess with DS things in the C package it gets its own empty stash to deal with. (Which DS all other packages that didn't use one version of the module or another get) DS I suppose that's a fancy way of saying namespaces created by used modules DS are private to the package using them. (Though that still leaves the issue DS of what happens when package B uses something from package C which wasn't DS created on the use, but then I'd probably just say "you get your version of DS C. Nyah!") -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
RFC 78 (v1) Improved Module Versioning And Searching
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Improved Module Versioning And Searching =head1 VERSION Maintainer: Steve Simmons [EMAIL PROTECTED] Date: 8 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 78 CVSID: $Id: modules.pod,v 0.3 2000/08/09 04:01:14 scs Exp $ =head1 ABSTRACT Modern production systems may have many versions of different modules in use simultaneously. Workarounds are possible, but they lead to a vast spaghetti of fragile installation webs. This proposal will attempt to redefine module versioning and its handling in a way that is fully upward compatible but solves the current problems. An up-to-the-instant version of this RFC will be posted as HTML at Chttp://www.nnaf.net/~scs/Perl6/RFCxx.html as soon as I know the RFC number. =head1 DESCRIPTION There are several classes of problem with the current module versioning and searching, which will be discussed separately. The solutions proposed overlap, and are discussed in BIMPLEMENTATION below. =head2 Current Implementation Is Broken These problems are ones in which I would go so far as to say that the current (Cperl5) performance is actually broken. =head3 Discovery Of Older Versions Aborts Searches Currently a statement use foo 1.2; can cause Cperl to search C@INC until it finds a Cfoo.pm file or exhausts the search path. When a Cfoo.pm, its CVERSION is checked against the one requested in the Cuse statement. If the Cfoo.pm version is less than 1.2, Cperl immediately gives an error message and halts the compilation. A satisfactory version may exist elsewhere in C@INC, but it is not searched for. =head3 First Module Discovered May Not Be Newest I believe that when a programmer writes use module; `Do What I Mean' should find the newest version of the module present on the C@INC search path. Instead, the very first Cmodule.pm file found is taken, regardless of the presence of others on the path. =head2 Current Methods Are Insufficient for Complex Installations Deployment of perl modules in high-reliability or widely shared environments often requires multiple versions of modules installed simultaneously. (Comments `but that's a bad idea' will be cheerfully ignored -- if I could control what other departments need, I would). This leads to an endless proliferation of Cuse lib directories and ever-more-pervasive `silos of development.' Part of the problem is the limitations of the current system in how modules are versioned and how Cperl decides which version to load. In worst case, code such as use lib '/path/to/department/module/versionX'; use module ;# To get version X for sure no use lib '/path/to/department/module/versionX'; has been found in production equipment. Why does such bogosity occur? It's an attempt to solve both the above problems and the deployment issues which follow below. =head3 New Module Releases Can Break Existing Scripts IWorking tools persist. An application which does its job well will live as long as the problem it addresses. This means old code may continue running for a long time. For Cperl itself, most sites solve this problem by having the perl invocation include versioning: #!/usr/bin/perl5.005 The indicated version will likely remain installed and stable as long as the script which uses it and the platform on which that script runs. The proliferation and increasing use of modules is generally a good thing. However, installation of new modules can and sometimes does break existing scripts. Workarounds for this problem are cumbersome at best, and we have existence proofs in other languages that this can be handled better (notably Ctcl, but there are probably more). =head3 Test Systems Need Test Modules Mission-critical scripts often need to have a final test pass by releasing experimental versions onto productions systems alongside the production systems. The inflexibility of perl module versioning also contributes to difficulties in releasing systems for test. A new script may require significant changes to internals of one or more supporting modules. The changes need not be visible to existing scripts; if bugs are introduced then previously working systems may change or break in obscure ways. Ideally, there would be a mechanism by which CscriptI.new or CInewscript could be released simultaneously with an appropriate version of CmoduleI.new.pm or CInewmodule.pm while the previous version remains in place for older code. A more flexible mechanism for module version specification and searching can fix the problem. =head2 Proposed Solution I believe that relatively simple changes can be made to the version identification and module installation systems which will solve all the above problems. In addition, those changes should be largely upward compatible from current functioning; and if needed could be made 100% compatible. =head1 IMPLEMENTATION Several changes, working
