On Tue, Jun 04, 2002 at 12:59:38PM -0400, John Siracusa wrote:
> In the spirit of Simon's desire to see "radical changes" when appropriate, I
> propose the following high-level goals for 6PAN . . .
> 1. Multiple versions of the same module may be installed on a single system
> with no possibility of conflicts. That means no conflicts of any kind,
> whether it be in Perl code, XS-ish stuff, private shared libs, etc.
Larry has stated this as a goal, and in this thread on Tue, Jun 04,
2002 at 10:26:22AM -0700, Larry Wall wrote:
> Yes, I'm already on record that multiple installed versions will
> coexist peacably, certainly on disk, and to the extent that they can
> in memory. We can't stop two versions of a module from fighting over a
> shared resource, for instance . . .
And that's an issue that needs to be resolved -- modules are going to
have to be able to test for each others state of being loaded and have
some mechanisms to disambiguate and defer to each other. I won't go
down the sytactic rathole of what *that* entails, just noting it as an
issue.
Back to John S:
> : 2. Module packaging, expansion, and installation only requires a working
> : install of Perl 6 (unless the module contains non-Perl code, such as C,
> 3. Module removal should be as easy as installation.
Yes, yes.
> 1a. Modules may be "use"-ed in several ways (syntax ignored for now):
I addressed a few of these in RFC78 and quite a few more in an as-yet
unpublished rewrite of it; Larry mentioned a line or two of syntax in
a recent email that's not terribly dissimilar.
All the things you specify are relatively easy in the perl world. It's
mapping them into filenames and directories that @INC can use that
gets, er, interesting. However . . .
> 1b. 6PAN modules comply with an informal contract to maintain
> backward-compatibility within all N.MM versions, where N is constant. . .
IMHO it should be a stated requirement, just as one needs a Makefile.PL.
And while person's tweak is another persons incompatible blotch, we
ultimately have to defer to `in the opinion of the author.'
On Tue, Jun 04, 2002 at 10:11:40AM -0700, David Wheeler responds to
Johns stuff above:
> This might be asking too much -- it's not very perlish, in the sense of
> TIMTOWTDI. It might make sense for DKs, but different people may want to use
> the conventions their comfortable with. Perl is there for you to create
> applications (and APIs) the way you want, not the way the gods demand.
I must respectfully disagree. Perl has rules, and strict ones -- and
more than just the syntax and the semantics. Anyone can *change* perls
syntax, but they have to get buy-in from a fairly large and conservative
community to get it incorporated into perl. Why should we not be as
careful about 6PAN?
We could take this a step further -- let CPAN be the perl equivelent of
Sourceforge, but hold 6PAN to a higher standard. TIMTOWTDI.
> One thing I think is as important -- or perhaps more important -- is to
> enforce the presence of unit tests. There are a lot of modules on the CPAN
> that have no tests, and most of them suffer for it.
Yes, but . . .
> It shouldn't be required that all tests pass, however. A statement showing
> what platforms they pass on and what platforms they don't at the top of the
> download page would be good enough. But the tests have got to be there.
Actually, for 6PAN I think they should have to pass. And maybe we
need a bug submission setup, and status checks, and . . . OK, OK, I'll
stop now. They're nice ideas, but who bells the cat? The again, if
Tim O'Reilly wants to fund me I'd be happy to do it. :-)
On Tue, Jun 04, 2002 at 01:21:26PM -0400, John Siracusa wrote on
the same thread:
> Heh, I was going to suggest that new minor-version 6PAN submissions
> automatically have all the earlier minor-version test suites run against
> them before allowing them to go into the archive... :)
Yep, that too. Which means . . .
On Tue, Jun 04, 2002 at 10:57:15AM -0700, David Wheeler wrote:
> On 6/4/02 10:21 AM, "John Siracusa" <[EMAIL PROTECTED]> claimed:
> Hmmm...perhaps as a warning:
>
> All regression tests not passed. Do you still want to upload this module?
s/Do you still want to upload this module?/Upload rejected./
On Tue, Jun 04, 2002 at 10:26:22AM -0700, Larry Wall wrote:
> : 3. Module removal should be as easy as installation.
>
> Fine. There ought to be something in the metadata that says, "This version
> of this module hasn't been used since 2017." Then you can clear out the
> deadwood easily. Course, disk space will be a little cheaper by then, so
> maybe we'll just hang onto everything forever.
Nu? If you mean used in the sense of 'use foo', that would imply all
running programs would have to write some sort of usage db, or touch
a global file, or a lot of other things that I don't think are going to
fly.
> : 1c. Distinctions like "alpha", "beta", and "stable" need to be made
> : according to some convention (a la $VERSION...perhaps $STATUS?)
>
> Can probably burn that bridge when we get to it.
Frankly, I'd argue that nothing in 6PAN ought to be in alpha/beta state.
An author could make a package available that was in that condition,
but it shouldn't be uploaded to 6PAN. Once one has that restrition,
$STATUS isn't really needed. The adventurous will upload the alpha
code from the author and install it into the 6PAN tree by specifying some
sort of `force' flag. Thereafter, our adventurere is on his own.
On Tue, Jun 04, 2002 at 11:13:53AM -0700, Austin Hastings wrote:
> > : 1c. Distinctions like "alpha", "beta", and "stable" need to be made
> > : according to some convention (a la $VERSION...perhaps $STATUS?)
> >
> > Can probably burn that bridge when we get to it.
> >
>
> Been done before:
>
> 3.1.3. Examples
> The following examples of font names are derived from the screen fonts
> shipped with the X Consortium distribution.
>
> Charter 12 pt ...
> -Bitstream-Charter-Medium-R-Normal--12-120-75-75-P-68-IO8859-1
> Charter Bold 12 pt ...
> -Bitstream-Charter-Bold-R-Normal--12-120-75-75-P-76-ISO8859-1
> Charter Bold Italic 12 pt ...
> -Bitstream-Charter-Bold-I-Normal--12-120-75-75-P-75-ISO8859-1
> Charter Italic 12 pt ...
> -Bitstream-Charter-Medium-I-Normal--12-120-75-75-P-66-ISO8859-1
.. . .
I was about to run screaming from the room until reading the item a bit
closer. OK, yeah, a method of aliasing simple names to fully specified
modules (modulename, version, author, whatever...) would be a win. But
this still punts the issue of just how one determines what modules
are available on a system and how perl6 can quickly find and load all
the things that are appropriate. My current understanding (my hope)
is that just saying
use foo;
always gets you the latest foo. With (potentially) many modules having
the same name and multiple authors/versions, the current complexity of
the perl /lib tree could increase to the third power. That gonna be
very disk-intensive for every frigging perl script that runs.
The current perl module tree is pretty difficult for the average day to
day scripter to comprehend. I'd go even further and say that it's so
complex as to be unmanagable.
IMHO 6PAN and perl6? ought to bit the bullet and do indexing. The 'make
install' process for both perl6 and 6PAN additions ought to build an
index at the top of each appropriate branch, initially everything in @INC.
Some other quick points on the general topic:
o If you override the install location with some path that
isn't in @INC, `make install' should update the index.
o perl6 -w ought to warn of missing indexes, then do a brute
force search of any @INC element that lacks an index.
o perl6 needs a `use brute force' switch for those trees that have
out-of-date indexes but for which we don't want to otherwise
turn off warnings. Maybe "use searchlib 'foo';"?
In re putting everything for a given module into a given directory --
it's a good thought, but I foresee problems with shared libraries
(.so files). With a gigantic module like the Tk:: core, you don't always
want multiple copies of each shared lib for each Tk:: version. It just
ain't gonna fly. On the other hand, there's no reason that shared libs
couldn't be stored in a standard location and symlinked to. And when
the symlink count goes to zero, the file GC system could delete the .so.
--
STEP 4: PRACTICE THE RULE OF THREE: If an e-mail thread has gone back and
forth three times, it is time to pick up the phone.
from the 12-Step Program for email addicts,
http://www.time.com/time/columnist/taylor/article/0,9565,257188,00.html
