CPAN, Perl6, and module versioning

Wouldn't It Be Great® if it were possible to have multiple versions of a library installed? That would make things so much more convenient for CPAN contributors. Currently there's no sensible way to deprecate a component or change up a module's API.

How about if Perl6 modules were to be installed in directories corresponding to their major version number? So that version 2.15 of Foo::Bar, which might currently reside here:

/usr/local/lib/perl5/5.8.5/Foo/Bar.pm

... would be located here instead:

/usr/local/lib/perl6/6.0.0/2/Foo/Bar.pm

Extra added bonus: that would give us a place to put Perl6 modules on CPAN, since there isn't anything in 0::, 1::, etc.

UPDATE:Versioning IS great already in Perl6. (Thanktalus, Tanktalus.)
"In heaven, everything is fine..."

--
Marvin Humphrey
Rectangular Research ― http://www.rectangular.com

Comment on CPAN, Perl6, and module versioning Select or Download Code

Replies are listed 'Best First'.
Re: CPAN, Perl6, and module versioning by Tanktalus (Canon) on Oct 01, 2005 at 16:39 UTC
You should read the perl6 documentation that's out there. The versioning is already solved ;-) http://search.cpan.org/~ingy/Perl6-Bible-0.19/lib/Perl6/Bible/S11.pod details versioning - perhaps this will sate your desire ;-)	[reply]
Re^2: CPAN, Perl6, and module versioning by creamygoodness (Curate) on Oct 01, 2005 at 17:31 UTC
Thanks. I'll know where to look next time. :\ -- Marvin Humphrey Rectangular Research ― http://www.rectangular.com	[reply]
Re^2: CPAN, Perl6, and module versioning by eric256 (Parson) on Oct 02, 2005 at 18:23 UTC
I think I'm missing something. That link shows how to specify which version to include, but I don't see where it specifies how they are stored. Specificaly it says "Modules posted to CPAN or entered into any standard Perl 6 library are required to declare their full name so that installations can know where to keep them, such that multiple versions by different authors can coexist, all of them available to any installed version of Perl." Any ideas if that has been decided yet? /me considers overloading use to pull modules out of a database just for kicks. ;) ___________ Eric Hodges	[reply]
Re^2: CPAN, Perl6, and module versioning by tilly (Archbishop) on Oct 05, 2005 at 05:23 UTC
It is solved only for some definitions of solved. If you load 2 modules that try to load different versions of the same module, the result can be best described as "interesting". Sometimes it will work, but I wouldn't want to trust it. If that module happens to be a binary module that loads a C-level library, your chances at even limited success drop drastically. I firmly believe that a lot of work will go into making versioning work like the spec says, and then people will discover that trying to use the feature causes far more problems than it solves. Unfortunately they will only discover the problems after having committed themselves to the strategy for a while, and so will have created some nasty messes first.	[reply]
Re: CPAN, Perl6, and module versioning by nothingmuch (Priest) on Oct 01, 2005 at 16:50 UTC
I'd rather see `.../perl/lib/5.x.x/Foo-Bar-0.01/lib/Foo/Bar.pm .../perl/lib/5.x.x/Foo-Bar-0.01/auto/Foo/Bar.pm .../perl/lib/5.x.x/Foo-Bar-0.01/my-arch-and-processor/lib/Foo/Bar.so .../perl/lib/5.x.x/Foo-Bar-0.02/...` [download] But this is hard to do - the current loading mechanism is overloadable, but we don't have a way to specify what version (except for only), and there is so much psychological inertia in the current scheme. Perl 6 makes the author name and the module version explicit parts of the full namespace. You can use the short name, or specify whose `Foo::Bar` you want, and even what version. -nuffin zz zZ Z Z #!perl	[reply] [d/l] [select]