FAQ
I'm writing up my notes from an extensive IRC conversation with Jesse
Vincent. I offered to post it to cpan-workers for feedback.

He and I agree that there are significant benefits to the community to
using a single repository for both Perl 5 and Perl 6 distributions.
We worked through some differences of opinion in various ways this
could be accomplished harmoniously and came up with what we think is a
reasonable approach using much of the existing infrastructure.

We agreed on several things:

* We want to avoid bikeshed discussions of "CPAN/PAUSE 2.0"
* We want to use the existing PAUSE/CPAN author credentials for both
Perl 5 and Perl 6
* We want to use the existing PAUSE upload infrastructure with as
few changes as possible
* We want to consider "uploading" and "indexing" as separate issues [1]
* We want to keep the existing package index files for Perl 5 only
* We want to distinguish between Perl 5 and Perl 6 distributions
within the file system

I will explain the last point briefly as it was the crux of our
discussion. While the 02packages file is a useful index of "things
that are Perl 5 modules", it does not include developer distributions,
outdated distributions, distributions without modules, etc. It is a
subset of Perl 5 things, not complete index. Any tool that wants to
look at Perl 5 things that aren't in the 02packages file is forced to
look at the only other "index" available -- the file system. If we
separate Perl 5 and Perl 6 distributions within the file system, we
can distinguish between them easily and without relying on indexes,
meta data files or other elements of complexity.

Our proposal is for Perl 6 modules to be uploaded into a 'perl6'
subdirectory of a CPAN author's directory like so:

...D/DA/DAGOLDEN/perl6/Foo-Bar-1.23.tar.gz

PAUSE already supports uploading to subdirectories today, so the
functionality exists NOW without any changes to PAUSE. It requires a
*convention* of authors uploading their Perl 6 distributions to the
right place and Jesse is looking into who is writing the Perl 6
"uploader" client (and will encourage them to join cpan-workers). If
uploads are automated with tools, it would be a fairly simple matter
to have the tools follow the convention.

We also thought that it might be relatively easy for to add
radio-boxes to the PAUSE upload page to indicate Perl 5 or Perl 6 and
to place Perl 6 distributions into the proper directory without it
having to be specified explicitly. (Whether it *must* be specified as
one or the other, which would require updates to Perl 5 tools like
CPAN::Uploader I will defer to Andreas' judgment.)

This seemed like a very easy way to let Perl 5 and Perl 6 co-habitate
nicely on CPAN, without any change to the existing infrastructure. It
makes it easier (though not foolproof) for PAUSE or other indexers
like the ones for CP5XXXAN or BackPAN to differentiate Perl 5 and Perl
6 distributions. [2]

We considered whether we should encourage new Perl 5 uploads to be put
in a 'perl5' subdirectory but decided that historical precedent was
too strong and it would be a point of unnecessary controversy.

[1] There will, of course, eventually be a need down the line for Perl
6 package/distribution indexing, but that is true regardless of
where/how files are uploaded.

[2] Indexers may still need to double check inside things in case they
were put in the wrong place.

-- David

Search Discussions

  • Eric Wilhelm at Apr 13, 2010 at 10:36 pm
    # from David Golden
    # on Tuesday 13 April 2010 10:48:
    Our proposal is for Perl 6 modules to be uploaded into a 'perl6'
    subdirectory of a CPAN author's directory like so:

    ...D/DA/DAGOLDEN/perl6/Foo-Bar-1.23.tar.gz
    This would require changes to any tools which think that
    D/DA/DAGOLDEN/*/ are all simple subdirectories with no special
    conventions attached to them.

    I would prefer that the perl6/ part of the tree be created a few levels
    up - e.g. perl6/authors/id/D/DA/DAGOLDEN/.

    Aside from being able to start uploading without changing PAUSE, what is
    gained by putting the perl6/ directory in this deep, and how many other
    things are going to have to permanently bear the complexity of having
    this one special directory land in the middle of the existing
    filesystem? Further: where (if they exist at all) will the various
    symlinks go for perl6 dists?

    I'm thinking that rooting a completely new tree at /perl6/ might also
    make it possible to repurpose perl5 dist tools for handling perl6 code
    by simply appending '/perl6' to the base mirror uri. (Assuming that we
    make the perl6 tree look substantially similar to the existing one.)
    PAUSE already supports uploading to subdirectories today, so the
    functionality exists NOW without any changes to PAUSE.  It requires a
    *convention* of authors uploading their Perl 6 distributions to the
    right place ...
    ...add
    radio-boxes to the PAUSE upload page to indicate Perl 5 or Perl 6 and
    to place Perl 6 distributions into the proper directory without it
    having to be specified explicitly.
    If you're changing the upload tool and indexer, it would seem that
    making them auto-detect perl6-ness (via the metafile?) would be less
    error-prone for users.

    I wonder: is it possible/feasible to run a second instance of PAUSE as
    a perl6-mode without extensive changes? Presumably, requiring a
    metafile should put the indexer into a flow where it isn't trying to do
    anything perl5-specific, so then you just need some new tables?

    Or, a perl6-only fork/rewrite of it if someone is so inclined.

    --Eric
    --
    software: a hypothetical exercise which happens to compile.
    ---------------------------------------------------
    http://scratchcomputing.com
    ---------------------------------------------------
  • Tim Bunce at Apr 14, 2010 at 11:49 am

    On Tue, Apr 13, 2010 at 01:48:28PM -0400, David Golden wrote:

    He and I agree that there are significant benefits to the community to
    using a single repository for both Perl 5 and Perl 6 distributions. +1
    We worked through some differences of opinion in various ways this
    could be accomplished harmoniously and came up with what we think is a
    reasonable approach using much of the existing infrastructure.

    We agreed on several things:

    * We want to avoid bikeshed discussions of "CPAN/PAUSE 2.0"
    * We want to use the existing PAUSE/CPAN author credentials for both
    Perl 5 and Perl 6
    * We want to use the existing PAUSE upload infrastructure with as
    few changes as possible
    * We want to consider "uploading" and "indexing" as separate issues [1]
    Upload is essentially 'drop a distro tarball' + 'claim ownership'
    (+ and optional 'put in this directory') which then queues it for
    automated indexing later.

    PAUSE already unpacks and examines the uploaded tarball as part of
    indexing. It's reasonable to assume that we'll be using a META.json
    file (or .yml I guess) for distributions that require perl6.
    The META spec already includes a 'requires' element that can be used to
    specify a minimum perl version, so I suggest we use that to identify
    that perl6 is required:

    requires:
    perl: 6.0

    A very simple and natural use of the existing mechanisms.
    http://www.mail-archive.com/cpan-workers@perl.org/msg00505.html
    If we separate Perl 5 and Perl 6 distributions within the file system,
    we can distinguish between them easily and without relying on indexes,
    meta data files or other elements of complexity.
    True, but is that *really* a significant need? Why bother?

    It seems to me that all that's needed in the short term is for PAUSE to
    not index uploads where it detects perl >= 6 in META requires.
    (Which seems pretty trivial on the face of it.)

    Once that's in place then perl6 distros can be uploaded freely
    while new indexing arrangements are being worked out.
    We also thought that it might be relatively easy for to add
    radio-boxes to the PAUSE upload page to indicate Perl 5 or Perl 6 and
    to place Perl 6 distributions into the proper directory without it
    having to be specified explicitly. (Whether it *must* be specified as
    one or the other, which would require updates to Perl 5 tools like
    CPAN::Uploader I will defer to Andreas' judgment.)
    No need for a radio-box if PAUSE auto-detects from the META file.

    Tim.
  • Ovid at Apr 14, 2010 at 12:01 pm

    --- On Wed, 14/4/10, Tim Bunce wrote:

    No need for a radio-box if PAUSE auto-detects from the META
    file.

    Tim.
    Agreed, but you know you're going to see this and variants thereof:

    requires:
    perl: 6,0

    Should that be a rejection for unknown format? I would think so. Better to fail early than have junk spread throughout the CPAN.

    Cheers,
    Ovid
  • David Golden at Apr 14, 2010 at 12:09 pm

    On Wed, Apr 14, 2010 at 7:48 AM, Tim Bunce wrote:
    Upload is essentially 'drop a distro tarball' + 'claim ownership'
    (+ and optional 'put in this directory') which then queues it for
    automated indexing later.
    I believe it's important to distinguish those activities. "drop a
    tarball into a directory" is file manipulation, whereas "claim
    ownership" is a form of indexing. It's not clear to me that Perl 5
    semantics for namespace ownership have any relevance for Perl 6.
    The META spec already includes a 'requires' element that can be used to
    specify a minimum perl version, so I suggest we use that to identify
    that perl6 is required:

    requires:
    perl: 6.0
    I believe this is an acceptable option, but only for expediency. The
    CPAN Meta Spec has many elements which are specific to Perl 5's
    approach to indexing. After spending a lot of time considering it, I
    do not think it will serve the needs of Perl 6 in its current form.
    Nor, for that matter, do I think that Perl 6 semantics for packages,
    authorities, modules, distributions, versions, etc. can be considered
    stable (just like the rest of the language).

    If Perl 6 authors choose to use the CPAN Meta Spec for Perl 6, I see
    that akin to doctors proscribing off-label medicines to patients. It
    might address the symptoms, but the long term side-effects are
    unknown.
    If we separate Perl 5 and Perl 6 distributions within the file system,
    we can distinguish between them easily and without relying on indexes,
    meta data files or other elements of complexity.
    True, but is that *really* a significant need? Why bother?
    There are only two "indexes" on CPAN that matter. The first is
    02packages, which is a map of Perl 5 namespaces to filepaths. The
    other is the filesystem, which organizes files into hierarchies.
    Tools that wish to operate only on Perl 5 distributions or only on
    Perl 6 distributions need a way to distinguish between them.

    Using the filesystem as an index is possible immediately, without
    additional effort. It also would allow mirror operators who choose
    not to mirror Perl 5 or Perl 6 to easily prune out portions of the
    filetree during rsync.

    -- David
  • Graham Barr at Apr 14, 2010 at 12:55 pm

    On Apr 14, 2010, at 6:48 AM, Tim Bunce wrote:
    If we separate Perl 5 and Perl 6 distributions within the file system,
    we can distinguish between them easily and without relying on indexes,
    meta data files or other elements of complexity.
    True, but is that *really* a significant need? Why bother?
    If we do not, then we need a different naming convention for the tar files.
    Otherwise how can we upload FooBar-1.45.tar.gz that works for perl5 and also
    FooBar-1.45.tar.gz that is written in perl6

    The perl5 version may work with perl6, but no visa-versa.

    I think there needs to be some separation in the file space in order
    to do this. Using a directory perl6/ and controlling that via PAUSE
    seems a bit more reliable and consistent than expecting users to use
    a particular convention not to confuse files.
    We also thought that it might be relatively easy for to add
    radio-boxes to the PAUSE upload page to indicate Perl 5 or Perl 6 and
    to place Perl 6 distributions into the proper directory without it
    having to be specified explicitly. (Whether it *must* be specified as
    one or the other, which would require updates to Perl 5 tools like
    CPAN::Uploader I will defer to Andreas' judgment.)
    No need for a radio-box if PAUSE auto-detects from the META file.
    I think there are arguments both for and against. For example
    what to do if PAUSE cannot detect ?

    Graham.
  • Elaine Ashton at Apr 14, 2010 at 2:33 pm

    On Apr 14, 2010, at 8:55 AM, Graham Barr wrote:
    On Apr 14, 2010, at 6:48 AM, Tim Bunce wrote:

    If we separate Perl 5 and Perl 6 distributions within the file system,
    we can distinguish between them easily and without relying on indexes,
    meta data files or other elements of complexity.
    True, but is that *really* a significant need? Why bother?
    If we do not, then we need a different naming convention for the tar files.
    Otherwise how can we upload FooBar-1.45.tar.gz that works for perl5 and also
    FooBar-1.45.tar.gz that is written in perl6

    The perl5 version may work with perl6, but no visa-versa.

    I think there needs to be some separation in the file space in order
    to do this. Using a directory perl6/ and controlling that via PAUSE
    seems a bit more reliable and consistent than expecting users to use
    a particular convention not to confuse files.
    I remember bringing this up in one of the panel discussions at OSCON following the decision to go with Perl6 as it will prove to be problematic, especially given the limitations in the namespace, and I think they will need to be very separate. I haven't kept up with P6 development and the module conventions, but I had thought this particular issue had been solved with requiring 'Perl6::' or something similar to distinguish P5 from P6 modules. Briefly looking at the P6 synopsis for CPAN ( http://perlcabal.org/syn/S22.html ) still gives me the impression that there will be a version prefix and that cpan6 is still in development, both of which still seem like very good ideas.
    We also thought that it might be relatively easy for to add
    radio-boxes to the PAUSE upload page to indicate Perl 5 or Perl 6 and
    to place Perl 6 distributions into the proper directory without it
    having to be specified explicitly. (Whether it *must* be specified as
    one or the other, which would require updates to Perl 5 tools like
    CPAN::Uploader I will defer to Andreas' judgment.)
    No need for a radio-box if PAUSE auto-detects from the META file.
    I think there are arguments both for and against. For example
    what to do if PAUSE cannot detect ?
    In a post-P6 world, I'd say if it can't be detected, it should be rejected since it will be an important, if not essential, piece of information for PAUSE.

    e.
  • Ovid at Apr 14, 2010 at 1:14 pm

    --- On Wed, 14/4/10, Jesse Vincent wrote:

    From: Jesse Vincent <jesse@fsck.com>
    Agreed, but you know you're going to see this and
    variants thereof:
    requires:
    perl: 6,0

    Should that be a rejection for unknown format? I would
    think so.  Better to fail early than have junk spread
    throughout the CPAN.
    Just to confirm, you mean "refuse to index" not "refuse to
    propagate
    the file", right?
    To be honest, I'm not sure. Definitely don't index that, but if someone presents an invalid version, you could wind up with a lot of junk that might be hard to clean out.

    Of course, since I won't be the one cleaning the junk, I'm not worried. If my CPAN client was picking up bogus entries in indices, then I'd be worried :)

    Cheers,
    Ovid
  • Jesse Vincent at Apr 14, 2010 at 1:18 pm

    On Wed, Apr 14, 2010 at 06:14:45AM -0700, Ovid wrote:
    --- On Wed, 14/4/10, Jesse Vincent wrote:
    From: Jesse Vincent <jesse@fsck.com>
    Agreed, but you know you're going to see this and
    variants thereof:
    requires:
    perl: 6,0

    Should that be a rejection for unknown format? I would
    think so.  Better to fail early than have junk spread
    throughout the CPAN.
    Just to confirm, you mean "refuse to index" not "refuse to
    propagate
    the file", right?
    To be honest, I'm not sure. Definitely don't index that, but if someone presents an invalid version, you could wind up with a lot of junk that might be hard to clean out.
    That would be a pretty policy significant change. Historically, so long as your
    tarball is well-formed, you can upload line-noise[1] to PAUSE and it will
    propagate it.

    -Jesse


    [1] Consequently, changing this would entirely break the ability to upload Perl 4 code to the CPAN.
  • David Golden at Apr 14, 2010 at 1:32 pm

    On Wed, Apr 14, 2010 at 9:18 AM, Jesse Vincent wrote:
    That would be a pretty policy significant change. Historically, so long as your
    tarball is well-formed, you can upload line-noise[1] to PAUSE and it will
    propagate it.
    Tautology. It's the "[Perl programming] Authors Upload Server" and as
    we all know, Perl is just line noise anyway. :-)

    David
  • Graham Barr at Apr 14, 2010 at 4:18 pm

    On Apr 14, 2010, at 8:18 AM, Jesse Vincent wrote:
    On Wed, Apr 14, 2010 at 06:14:45AM -0700, Ovid wrote:
    --- On Wed, 14/4/10, Jesse Vincent wrote:
    From: Jesse Vincent <jesse@fsck.com>
    Agreed, but you know you're going to see this and
    variants thereof:
    requires:
    perl: 6,0

    Should that be a rejection for unknown format? I would
    think so. Better to fail early than have junk spread
    throughout the CPAN.
    Just to confirm, you mean "refuse to index" not "refuse to
    propagate
    the file", right?
    To be honest, I'm not sure. Definitely don't index that, but if someone presents an invalid version, you could wind up with a lot of junk that might be hard to clean out.
    That would be a pretty policy significant change. Historically, so long as your
    tarball is well-formed, you can upload line-noise[1] to PAUSE and it will
    propagate it.
    propagate it yes, but not everything gets indexed. to get indexed you have to
    follow certain rules. for example if you leave the blib/ directory in your
    tarball it will not be indexed.
    [1] Consequently, changing this would entirely break the ability to upload Perl 4 code to the CPAN.
    nope. it just would not be indexed. but then perl4 code may not get indexed today either

    Graham.
  • David Cantrell at Apr 14, 2010 at 4:37 pm

    On Wed, Apr 14, 2010 at 11:17:55AM -0500, Graham Barr wrote:

    [1] Consequently, changing this would entirely break the ability to upload Perl 4 code to the CPAN.
    nope. it just would not be indexed. but then perl4 code may not get indexed today either
    It has to have .pm files to be indexed, and at least one of them has to
    have a $VERSION in it in such a way that PAUSE can parse. The Magic for
    that is in PAUSE::pmfile::parse_version_safely in mldistwatch.pm.

    --
    David Cantrell | Reality Engineer, Ministry of Information

    What a lovely day! Now watch me spoil it for you.
  • Tim Bunce at Apr 14, 2010 at 6:27 pm

    On Wed, Apr 14, 2010 at 08:57:04AM -0400, Jesse Vincent wrote:
    Agreed, but you know you're going to see this and variants thereof:

    requires:
    perl: 6,0

    Should that be a rejection for unknown format? I would think so. Better to fail early than have junk spread throughout the CPAN.
    Just to confirm, you mean "refuse to index" not "refuse to propagate
    the file", right?
    Right.

    Tim.
  • Adam Kennedy at Apr 15, 2010 at 12:53 am
    Alternative option, when we switch to Perl 6 also take the opportunity
    to switch to a specific named extension.

    D/DA/DAGOLDEN/Foo-Bar-1.23.c6z

    The directory option doesn't cover the case where you are installing
    from arbitrary URLs as supported by cpanplus, pip and cpanminus. The
    perl6 directory option could be useful for the indexer, but it doesn't
    scale to the darkpan.

    Secondary advantage would be that now "Perl 5 Applications" can be
    typed by your desktop OS and Perl software can be double-click
    installed or action-hooked by your browser.

    I've been meaning to propose for a while that for CPAN Perl 5 we drop
    support for everything other than tar.gz (we can talk about the need
    for zip files later) and encourage a switch to something like

    D/DA/DAGOLDEN/Foo-Bar-1.23.cpan

    Adam K
    On Wed, Apr 14, 2010 at 3:48 AM, David Golden wrote:
    I'm writing up my notes from an extensive IRC conversation with Jesse
    Vincent.  I offered to post it to cpan-workers for feedback.

    He and I agree that there are significant benefits to the community to
    using a single repository for both Perl 5 and Perl 6 distributions.
    We worked through some differences of opinion in various ways this
    could be accomplished harmoniously and came up with what we think is a
    reasonable approach using much of the existing infrastructure.

    We agreed on several things:

    * We want to avoid bikeshed discussions of "CPAN/PAUSE 2.0"
    * We want to use the existing PAUSE/CPAN author credentials for both
    Perl 5 and Perl 6
    * We want to use the existing PAUSE upload infrastructure with as
    few changes as possible
    * We want to consider "uploading" and "indexing" as separate issues [1]
    * We want to keep the existing package index files for Perl 5 only
    * We want to distinguish between Perl 5 and Perl 6 distributions
    within the file system

    I will explain the last point briefly as it was the crux of our
    discussion.  While the 02packages file is a useful index of "things
    that are Perl 5 modules", it does not include developer distributions,
    outdated distributions, distributions without modules, etc.  It is a
    subset of Perl 5 things, not complete index.  Any tool that wants to
    look at Perl 5 things that aren't in the 02packages file is forced to
    look at the only other "index" available -- the file system.  If we
    separate Perl 5 and Perl 6 distributions within the file system, we
    can distinguish between them easily and without relying on indexes,
    meta data files or other elements of complexity.

    Our proposal is for Perl 6 modules to be uploaded into a 'perl6'
    subdirectory of a CPAN author's directory like so:

    ...D/DA/DAGOLDEN/perl6/Foo-Bar-1.23.tar.gz

    PAUSE already supports uploading to subdirectories today, so the
    functionality exists NOW without any changes to PAUSE.  It requires a
    *convention* of authors uploading their Perl 6 distributions to the
    right place and Jesse is looking into who is writing the Perl 6
    "uploader" client (and will encourage them to join cpan-workers).  If
    uploads are automated with tools, it would be a fairly simple matter
    to have the tools follow the convention.

    We also thought that it might be relatively easy for to add
    radio-boxes to the PAUSE upload page to indicate Perl 5 or Perl 6 and
    to place Perl 6 distributions into the proper directory without it
    having to be specified explicitly.  (Whether it *must* be specified as
    one or the other, which would require updates to Perl 5 tools like
    CPAN::Uploader I will defer to Andreas' judgment.)

    This seemed like a very easy way to let Perl 5 and Perl 6 co-habitate
    nicely on CPAN, without any change to the existing infrastructure.  It
    makes it easier (though not foolproof) for PAUSE or other indexers
    like the ones for CP5XXXAN or BackPAN to differentiate Perl 5 and Perl
    6 distributions. [2]

    We considered whether we should encourage new Perl 5 uploads to be put
    in a 'perl5' subdirectory but decided that historical precedent was
    too strong and it would be a point of unnecessary controversy.

    [1] There will, of course, eventually be a need down the line for Perl
    6 package/distribution indexing, but that is true regardless of
    where/how files are uploaded.

    [2] Indexers may still need to double check inside things in case they
    were put in the wrong place.

    -- David
  • Adam Kennedy at Apr 15, 2010 at 12:54 am
    That should be "Perl 6 Applications"
    On Thu, Apr 15, 2010 at 10:53 AM, Adam Kennedy wrote:
    Alternative option, when we switch to Perl 6 also take the opportunity
    to switch to a specific named extension.

    D/DA/DAGOLDEN/Foo-Bar-1.23.c6z

    The directory option doesn't cover the case where you are installing
    from arbitrary URLs as supported by cpanplus, pip and cpanminus. The
    perl6 directory option could be useful for the indexer, but it doesn't
    scale to the darkpan.

    Secondary advantage would be that now "Perl 5 Applications" can be
    typed by your desktop OS and Perl software can be double-click
    installed or action-hooked by your browser.

    I've been meaning to propose for a while that for CPAN Perl 5 we drop
    support for everything other than tar.gz (we can talk about the need
    for zip files later) and encourage a switch to something like

    D/DA/DAGOLDEN/Foo-Bar-1.23.cpan

    Adam K
    On Wed, Apr 14, 2010 at 3:48 AM, David Golden wrote:
    I'm writing up my notes from an extensive IRC conversation with Jesse
    Vincent.  I offered to post it to cpan-workers for feedback.

    He and I agree that there are significant benefits to the community to
    using a single repository for both Perl 5 and Perl 6 distributions.
    We worked through some differences of opinion in various ways this
    could be accomplished harmoniously and came up with what we think is a
    reasonable approach using much of the existing infrastructure.

    We agreed on several things:

    * We want to avoid bikeshed discussions of "CPAN/PAUSE 2.0"
    * We want to use the existing PAUSE/CPAN author credentials for both
    Perl 5 and Perl 6
    * We want to use the existing PAUSE upload infrastructure with as
    few changes as possible
    * We want to consider "uploading" and "indexing" as separate issues [1]
    * We want to keep the existing package index files for Perl 5 only
    * We want to distinguish between Perl 5 and Perl 6 distributions
    within the file system

    I will explain the last point briefly as it was the crux of our
    discussion.  While the 02packages file is a useful index of "things
    that are Perl 5 modules", it does not include developer distributions,
    outdated distributions, distributions without modules, etc.  It is a
    subset of Perl 5 things, not complete index.  Any tool that wants to
    look at Perl 5 things that aren't in the 02packages file is forced to
    look at the only other "index" available -- the file system.  If we
    separate Perl 5 and Perl 6 distributions within the file system, we
    can distinguish between them easily and without relying on indexes,
    meta data files or other elements of complexity.

    Our proposal is for Perl 6 modules to be uploaded into a 'perl6'
    subdirectory of a CPAN author's directory like so:

    ...D/DA/DAGOLDEN/perl6/Foo-Bar-1.23.tar.gz

    PAUSE already supports uploading to subdirectories today, so the
    functionality exists NOW without any changes to PAUSE.  It requires a
    *convention* of authors uploading their Perl 6 distributions to the
    right place and Jesse is looking into who is writing the Perl 6
    "uploader" client (and will encourage them to join cpan-workers).  If
    uploads are automated with tools, it would be a fairly simple matter
    to have the tools follow the convention.

    We also thought that it might be relatively easy for to add
    radio-boxes to the PAUSE upload page to indicate Perl 5 or Perl 6 and
    to place Perl 6 distributions into the proper directory without it
    having to be specified explicitly.  (Whether it *must* be specified as
    one or the other, which would require updates to Perl 5 tools like
    CPAN::Uploader I will defer to Andreas' judgment.)

    This seemed like a very easy way to let Perl 5 and Perl 6 co-habitate
    nicely on CPAN, without any change to the existing infrastructure.  It
    makes it easier (though not foolproof) for PAUSE or other indexers
    like the ones for CP5XXXAN or BackPAN to differentiate Perl 5 and Perl
    6 distributions. [2]

    We considered whether we should encourage new Perl 5 uploads to be put
    in a 'perl5' subdirectory but decided that historical precedent was
    too strong and it would be a point of unnecessary controversy.

    [1] There will, of course, eventually be a need down the line for Perl
    6 package/distribution indexing, but that is true regardless of
    where/how files are uploaded.

    [2] Indexers may still need to double check inside things in case they
    were put in the wrong place.

    -- David
  • Ricardo Signes at Apr 15, 2010 at 1:42 am
    * Adam Kennedy [2010-04-14T20:53:15]
    Alternative option, when we switch to Perl 6 also take the opportunity
    to switch to a specific named extension.

    D/DA/DAGOLDEN/Foo-Bar-1.23.c6z
    I haven't wanted to get into this thread, but I will say that I had the same
    idea as Adam, and didn't think it was crazy.

    --
    rjbs
  • David Golden at Apr 15, 2010 at 1:54 am

    On Wed, Apr 14, 2010 at 8:53 PM, Adam Kennedy wrote:
    I've been meaning to propose for a while that for CPAN Perl 5 we drop
    support for everything other than tar.gz (we can talk about the need
    for zip files later) and encourage a switch to something like

    D/DA/DAGOLDEN/Foo-Bar-1.23.cpan
    +1 (reserving the option to bikeshed about the extension)

    Extending the idea to .pm6, .pl6, etc. would seem useful as well (sadly).

    David
  • Jesse Vincent at Apr 15, 2010 at 1:59 am

    On Wed, Apr 14, 2010 at 09:53:45PM -0400, David Golden wrote:
    On Wed, Apr 14, 2010 at 8:53 PM, Adam Kennedy wrote:
    I've been meaning to propose for a while that for CPAN Perl 5 we drop
    support for everything other than tar.gz (we can talk about the need
    for zip files later) and encourage a switch to something like

    D/DA/DAGOLDEN/Foo-Bar-1.23.cpan
    +1 (reserving the option to bikeshed about the extension)

    -1

    Forcing an extension makes all sorts of tools that previously "just
    worked" with a tarball suddenly start to fail.
  • Tim Bunce at Apr 15, 2010 at 2:14 pm

    On Wed, Apr 14, 2010 at 09:59:32PM -0400, Jesse Vincent wrote:
    On Wed, Apr 14, 2010 at 09:53:45PM -0400, David Golden wrote:
    On Wed, Apr 14, 2010 at 8:53 PM, Adam Kennedy wrote:
    I've been meaning to propose for a while that for CPAN Perl 5 we drop
    support for everything other than tar.gz (we can talk about the need
    for zip files later) and encourage a switch to something like

    D/DA/DAGOLDEN/Foo-Bar-1.23.cpan
    +1 (reserving the option to bikeshed about the extension)
    -1

    Forcing an extension makes all sorts of tools that previously "just
    worked" with a tarball suddenly start to fail.
    -1

    It's also the wrong place to encode version information.

    Tim.
  • David Golden at Apr 15, 2010 at 2:23 pm

    On Thu, Apr 15, 2010 at 10:14 AM, Tim Bunce wrote:
    On Wed, Apr 14, 2010 at 09:59:32PM -0400, Jesse Vincent wrote:>> Forcing an extension makes all sorts of tools that previously "just
    worked" with a tarball suddenly start to fail.
    We've dealt with it in the past.

    However, I'm inclined to think that going that way means an entirely
    new client that is designed for .cpan files. This is more akin to
    PPM, except non binary. The question in my mind is what this gains us
    beyond "double-clickability" for Windows. (Which is a non-trivial
    benefit -- e.g. see a *.cpan distribution on a web page, click it to
    install in Strawberry Perl). It might let us rethink some of the
    painful conventions of distribution tarballs today.
    It's also the wrong place to encode version information.
    Putting version info in the tarball name was necessary to avoid
    duplicate uploads, I suspect. It *is* a terrible place to be encoding
    version information, I agree.

    David
  • David Cantrell at Apr 15, 2010 at 2:29 pm

    On Thu, Apr 15, 2010 at 10:23:04AM -0400, David Golden wrote:

    However, I'm inclined to think that going that way means an entirely
    new client that is designed for .cpan files. This is more akin to
    PPM, except non binary. The question in my mind is what this gains us
    beyond "double-clickability" for Windows. (Which is a non-trivial
    benefit -- e.g. see a *.cpan distribution on a web page, click it to
    install in Strawberry Perl).
    This++

    And who says that only Windows users benefit? It would be damned useful
    for anyone distributing perl applications to end users via the CPAN -
    something that perl very much falls down on compared to certain other
    popular planguages. There's plenty of dumb bastards and lazy admins who
    use Mac OS X, Linux etc as well, you know :-)
    It's also the wrong place to encode version information.
    Putting version info in the tarball name was necessary to avoid
    duplicate uploads, I suspect. It *is* a terrible place to be encoding
    version information, I agree.
    Yes. Perhaps PAUSE 2.0 would accept an upload of any old .cpan file,
    inspect its contents, and then save it under a more appropriate name in
    the archive.

    --
    David Cantrell | Bourgeois reactionary pig

    Your call is important to me. To see if it's important to
    you I'm going to make you wait on hold for five minutes.
    All calls are recorded for blackmail and amusement purposes.
  • Curtis Jewell at Apr 15, 2010 at 2:56 pm

    On Thu, 15 Apr 2010 10:23 -0400, "David Golden" wrote:
    On Thu, Apr 15, 2010 at 10:14 AM, Tim Bunce wrote:
    On Wed, Apr 14, 2010 at 09:59:32PM -0400, Jesse Vincent wrote:>> Forcing an extension makes all sorts of tools that previously "just
    worked" with a tarball suddenly start to fail.
    We've dealt with it in the past.

    However, I'm inclined to think that going that way means an entirely
    new client that is designed for .cpan files. This is more akin to
    PPM, except non binary. The question in my mind is what this gains us
    beyond "double-clickability" for Windows. (Which is a non-trivial
    benefit -- e.g. see a *.cpan distribution on a web page, click it to
    install in Strawberry Perl). It might let us rethink some of the
    painful conventions of distribution tarballs today.
    It's also the wrong place to encode version information.
    Putting version info in the tarball name was necessary to avoid
    duplicate uploads, I suspect. It *is* a terrible place to be encoding
    version information, I agree.
    (Idea suddenly came to mind. If not workable, just take apart and
    reassemble until it does work.)

    Why don't we make the .cpan/.c6pan file (.c6pan) a JSON file, generated
    by PAUSE once the tarball is uploaded, with whatever information is
    required (a reference to the tarball, what version of perl is required,
    etc.) in order, when that file is passed to a CPAN client, to download
    and install the tarball.

    I don't see why a "double-clickable" file (or what-have-you equivalent)
    necessarily has to be the distribution tarball?

    That way, the tarball can keep its extension... best of both worlds yet?

    --Curtis
    --
    Curtis Jewell
    csjewell@cpan.org http://csjewell.dreamwidth.org/
    perl@csjewell.fastmail.us http://csjewell.comyr.org/perl/

    "Your random numbers are not that random" -- perl-5.10.1.tar.gz/util.c

    Strawberry Perl for Windows betas: http://strawberryperl.com/beta/
  • Adam Kennedy at Apr 15, 2010 at 3:49 pm
    This has already existed for about a year or more.

    See pip's .p5i file (which I think cpanminus also supports).

    Adam K

    On Fri, Apr 16, 2010 at 12:56 AM, Curtis Jewell
    wrote:
    Why don't we make the .cpan/.c6pan file (.c6pan) a JSON file, generated
    by PAUSE once the tarball is uploaded, with whatever information is
    required (a reference to the tarball, what version of perl is required,
    etc.) in order, when that file is passed to a CPAN client, to download
    and install the tarball.

    I don't see why a "double-clickable" file (or what-have-you equivalent)
    necessarily has to be the distribution tarball?

    That way, the tarball can keep its extension... best of both worlds yet?
  • Barbie at Apr 15, 2010 at 7:27 pm

    On Thu, Apr 15, 2010 at 08:56:04AM -0600, Curtis Jewell wrote:
    wrote:
    On Thu, Apr 15, 2010 at 10:14 AM, Tim Bunce wrote:
    On Wed, Apr 14, 2010 at 09:59:32PM -0400, Jesse Vincent wrote:>> Forcing an extension makes all sorts of tools that previously "just
    worked" with a tarball suddenly start to fail.
    We've dealt with it in the past.

    However, I'm inclined to think that going that way means an entirely
    new client that is designed for .cpan files. This is more akin to
    PPM, except non binary. The question in my mind is what this gains us
    beyond "double-clickability" for Windows. (Which is a non-trivial
    benefit -- e.g. see a *.cpan distribution on a web page, click it to
    install in Strawberry Perl). It might let us rethink some of the
    painful conventions of distribution tarballs today.
    (Idea suddenly came to mind. If not workable, just take apart and
    reassemble until it does work.)

    Why don't we make the .cpan/.c6pan file (.c6pan) a JSON file, generated
    by PAUSE once the tarball is uploaded, with whatever information is
    required (a reference to the tarball, what version of perl is required,
    etc.) in order, when that file is passed to a CPAN client, to download
    and install the tarball.
    This is essentially how PPM works. The PPD file points to a tarball, via
    an extension to the OSD file format. It would be easier to generate an
    installation configuration file, supported by a new installer that can
    cope with the double-click install of several OSes these days, than
    changing the package archive format.

    Changing PAUSE/CPAN to require a new package archive is likely to have a
    detrimental effect on Perl as a whole, as older installers will then be
    unable to install anything new. Upgrading is not always easy for some
    organisations (I know of one still using 5.6.1!).

    Mind you, if it means adding even more files to the filesystem, we come
    back to the discussion about rsync :(

    Cheers,
    Barbie.
    --
    Birmingham Perl Mongers <http://birmingham.pm.org>
    Memoirs Of A Roadie <http://barbie.missbarbell.co.uk>
    CPAN Testers Blog <http://blog.cpantesters.org>
    YAPC Conference Surveys <http://yapc-surveys.org>
  • Jan Dubois at Apr 15, 2010 at 7:50 pm

    On Thu, 15 Apr 2010, Barbie wrote:
    On Thu, Apr 15, 2010 at 08:56:04AM -0600, Curtis Jewell wrote:
    Why don't we make the .cpan/.c6pan file (.c6pan) a JSON file, generated
    by PAUSE once the tarball is uploaded, with whatever information is
    required (a reference to the tarball, what version of perl is required,
    etc.) in order, when that file is passed to a CPAN client, to download
    and install the tarball.
    This is essentially how PPM works. The PPD file points to a tarball, via
    an extension to the OSD file format. It would be easier to generate an
    installation configuration file, supported by a new installer that can
    cope with the double-click install of several OSes these days, than
    changing the package archive format.
    PPM4 actually supports putting the PPD file inside the tarball. When the
    tarball is downloaded with a .ppmx extension, then the client knows to
    extract the .ppd from inside the file and install everything else according
    to this .ppd file.

    The big problem with this scheme is though that is doesn't allow you
    to install prerequisites using this mechanism: You can double-click on
    a .ppmx file in a web browser and it can be downloaded and installed
    automatically. The ppm installer however no longer knows where the file
    came from, so it cannot look for prerequisites in the same place.

    This places the burden of installing prerequisites on the user, making
    the mechanism less useful than originally expected.

    One way around this would be to embed the file location inside the tarball
    itself, but that doesn't work if the tarballs may be mirrored to multiple
    locations.

    It would be nice if browsers would include the download URL in an alternate
    data stream (where possible, e.g. NTFS), but it looks like they only store
    the Internet.Zone information...

    Cheers,
    -Jan
  • Barbie at Apr 15, 2010 at 9:33 pm

    On Thu, Apr 15, 2010 at 12:50:29PM -0700, Jan Dubois wrote:

    PPM4 actually supports putting the PPD file inside the tarball. When the
    tarball is downloaded with a .ppmx extension, then the client knows to
    extract the .ppd from inside the file and install everything else according
    to this .ppd file.

    The big problem with this scheme is though that is doesn't allow you
    to install prerequisites using this mechanism: You can double-click on
    a .ppmx file in a web browser and it can be downloaded and installed
    automatically. The ppm installer however no longer knows where the file
    came from, so it cannot look for prerequisites in the same place.
    The last time I used PPM it was able to support multiple repositories,
    in the same way apt or yum does. I also thought it was able to install
    prerequisites from these if a local ppd wasn't found. I'd certainly like
    to see a double-click installer work like that :)

    Cheers,
    Barbie.
    --
    Birmingham Perl Mongers <http://birmingham.pm.org>
    Memoirs Of A Roadie <http://barbie.missbarbell.co.uk>
    CPAN Testers Blog <http://blog.cpantesters.org>
    YAPC Conference Surveys <http://yapc-surveys.org>
  • Jan Dubois at Apr 15, 2010 at 9:58 pm

    On Thu, 15 Apr 2010, Barbie wrote:
    On Thu, Apr 15, 2010 at 12:50:29PM -0700, Jan Dubois wrote:

    PPM4 actually supports putting the PPD file inside the tarball. When the
    tarball is downloaded with a .ppmx extension, then the client knows to
    extract the .ppd from inside the file and install everything else according
    to this .ppd file.

    The big problem with this scheme is though that is doesn't allow you
    to install prerequisites using this mechanism: You can double-click on
    a .ppmx file in a web browser and it can be downloaded and installed
    automatically. The ppm installer however no longer knows where the file
    came from, so it cannot look for prerequisites in the same place.
    The last time I used PPM it was able to support multiple repositories,
    in the same way apt or yum does. I also thought it was able to install
    prerequisites from these if a local ppd wasn't found. I'd certainly like
    to see a double-click installer work like that :)
    Yes, it certainly downloads prerequisites from the configured repositories.
    I was talking about downloading .ppmx files from some random website that
    you didn't configure first as a repository in the PPM client. The double-
    clicked file is not able to download additional prerequisites from that
    "random website" it came from itself. Think "private/internal repository
    of a bunch of interdependent modules".

    Once you have to configure the web site as a repo there isn't much advantage
    of installing modules via the browser compare to installing them with the
    PPM client:

    ppm repo add random http://random.example.com/repo
    ppm install my-random-module

    Cheers,
    -Jan
  • Barbie at Apr 15, 2010 at 10:36 pm

    On Thu, Apr 15, 2010 at 02:58:12PM -0700, Jan Dubois wrote:
    On Thu, 15 Apr 2010, Barbie wrote:
    On Thu, Apr 15, 2010 at 12:50:29PM -0700, Jan Dubois wrote:

    PPM4 actually supports putting the PPD file inside the tarball. When the
    tarball is downloaded with a .ppmx extension, then the client knows to
    extract the .ppd from inside the file and install everything else according
    to this .ppd file.

    The big problem with this scheme is though that is doesn't allow you
    to install prerequisites using this mechanism: You can double-click on
    a .ppmx file in a web browser and it can be downloaded and installed
    automatically. The ppm installer however no longer knows where the file
    came from, so it cannot look for prerequisites in the same place.
    The last time I used PPM it was able to support multiple repositories,
    in the same way apt or yum does. I also thought it was able to install
    prerequisites from these if a local ppd wasn't found. I'd certainly like
    to see a double-click installer work like that :)
    Yes, it certainly downloads prerequisites from the configured repositories.
    I was talking about downloading .ppmx files from some random website that
    you didn't configure first as a repository in the PPM client. The double-
    clicked file is not able to download additional prerequisites from that
    "random website" it came from itself. Think "private/internal repository
    of a bunch of interdependent modules".
    Got it. However, I was thinking the initial file (ppmx) would essentially
    be a stand-alone download, the installer would then revert to the
    predefined repos to download the prerequisites.

    In PPM's case there are only a few repos that try to keep up with CPAN,
    so knowing where the original repo was may be significant. However, if
    we're downloading from CPAN, then it would be reasonable to try and grab
    prereqs from a predefined set of CPAN mirrors.

    Cheers,
    Barbie.
    --
    Birmingham Perl Mongers <http://birmingham.pm.org>
    Memoirs Of A Roadie <http://barbie.missbarbell.co.uk>
    CPAN Testers Blog <http://blog.cpantesters.org>
    YAPC Conference Surveys <http://yapc-surveys.org>
  • Jan Dubois at Apr 15, 2010 at 10:56 pm

    On Thu, 15 Apr 2010, Barbie wrote:
    On Thu, Apr 15, 2010 at 02:58:12PM -0700, Jan Dubois wrote:
    Yes, it certainly downloads prerequisites from the configured repositories.
    I was talking about downloading .ppmx files from some random website that
    you didn't configure first as a repository in the PPM client. The double-
    clicked file is not able to download additional prerequisites from that
    "random website" it came from itself. Think "private/internal repository
    of a bunch of interdependent modules".
    Got it. However, I was thinking the initial file (ppmx) would essentially
    be a stand-alone download, the installer would then revert to the
    predefined repos to download the prerequisites.
    Yes, that's how it works.
    In PPM's case there are only a few repos that try to keep up with CPAN,
    so knowing where the original repo was may be significant.
    This is not important for modules on CPAN. It is important for modules
    whose prerequisites are *not* on CPAN and only exist in the same location
    as the original ppmx file.

    The way around this is probably to implement a protocol handler like

    ppm://random.example.com/repo/my-random-module.ppmx

    That way the browser would invoke the protocol handler with the full URL

    ppm install ppm://random.example.com/repo/my-random-module.ppmx

    instead of downloading the tarball via HTTP itself and then just passing
    a local filename to the installer:

    ppm install /tmp/downloads/my-random-module.ppmx

    Implementing a protocol handler for the major operating systems is somewhat
    more involved than just setting up a file extension/MIME type mapping though.
    However, if we're downloading from CPAN, then it would be reasonable
    to try and grab prereqs from a predefined set of CPAN mirrors.
    This all is not an issue if the "extension mechanism" only has to work
    for CPAN and can ignore the DarkPAN.

    One other issue that has been ignored so far is that neither the file
    extension nor the protocol scheme will work particular well if you have
    multiple Perl installations on your machine. You cannot direct the
    automatic download/install to a particular instance.

    Cheers,
    -Jan
  • Adam Kennedy at Apr 16, 2010 at 12:05 am
    I'm pretty sure that's true for all such systems, including things
    like .war files.

    Even if we split, say, Strawberry from ActivePerl, what if you have
    multiple installations of ActivePerl?

    Adam K
    On Fri, Apr 16, 2010 at 8:56 AM, Jan Dubois wrote:
    On Thu, 15 Apr 2010, Barbie wrote:
    On Thu, Apr 15, 2010 at 02:58:12PM -0700, Jan Dubois wrote:
    Yes, it certainly downloads prerequisites from the configured repositories.
    I was talking about downloading .ppmx files from some random website that
    you didn't configure first as a repository in the PPM client.  The double-
    clicked file is not able to download additional prerequisites from that
    "random website" it came from itself.  Think "private/internal repository
    of a bunch of interdependent modules".
    Got it. However, I was thinking the initial file (ppmx) would essentially
    be a stand-alone download, the installer would then revert to the
    predefined repos to download the prerequisites.
    Yes, that's how it works.
    In PPM's case there are only a few repos that try to keep up with CPAN,
    so knowing where the original repo was may be significant.
    This is not important for modules on CPAN.  It is important for modules
    whose prerequisites are *not* on CPAN and only exist in the same location
    as the original ppmx file.

    The way around this is probably to implement a protocol handler like

    ppm://random.example.com/repo/my-random-module.ppmx

    That way the browser would invoke the protocol handler with the full URL

    ppm install ppm://random.example.com/repo/my-random-module.ppmx

    instead of downloading the tarball via HTTP itself and then just passing
    a local filename to the installer:

    ppm install /tmp/downloads/my-random-module.ppmx

    Implementing a protocol handler for the major operating systems is somewhat
    more involved than just setting up a file extension/MIME type mapping though.
    However, if we're downloading from CPAN, then it would be reasonable
    to try and grab prereqs from a predefined set of CPAN mirrors.
    This all is not an issue if the "extension mechanism" only has to work
    for CPAN and can ignore the DarkPAN.

    One other issue that has been ignored so far is that neither the file
    extension nor the protocol scheme will work particular well if you have
    multiple Perl installations on your machine. You cannot direct the
    automatic download/install to a particular instance.

    Cheers,
    -Jan
  • Jan Dubois at Apr 16, 2010 at 12:23 am

    On Thu, 15 Apr 2010, Adam Kennedy wrote:

    I'm pretty sure that's true for all such systems, including things
    like .war files.

    Even if we split, say, Strawberry from ActivePerl, what if you have
    multiple installations of ActivePerl?
    That's what I'm saying:
    On Fri, Apr 16, 2010 at 8:56 AM, Jan Dubois wrote:
    Hmm, or what I'm going to say tomorrow, except I already said it today...

    [Mixing top/bottom quoting with wild adjustments to local time makes for
    an interesting thread history. :) ]
    One other issue that has been ignored so far is that neither the file
    extension nor the protocol scheme will work particular well if you have
    multiple Perl installations on your machine. You cannot direct the
    automatic download/install to a particular instance.
    The point being that all these "automatic" mechanisms break down for
    even slightly more complex installations. Explicitly calling a CPAN
    client/package manage doesn't have these problems.

    Meaning: there is a limit to the usefulness of playing around with file
    extensions (and protocol schemes). Given that changing the file extensions
    might create problems elsewhere it might simply not be worth it.

    Cheers,
    -Jan
  • Adam Kennedy at Apr 16, 2010 at 1:54 am

    On Fri, Apr 16, 2010 at 10:23 AM, Jan Dubois wrote:
    On Thu, 15 Apr 2010, Adam Kennedy wrote:
    Meaning: there is a limit to the usefulness of playing around with file
    extensions (and protocol schemes).  Given that changing the file extensions
    might create problems elsewhere it might simply not be worth it.
    I agree.

    But I hypothesise that the number of people with multiple Perl
    installations, and thus for which this problem applies, are low to
    negligible compared to the majority. And further, that the people who
    ARE in this situation are the same people that are most able to take
    care of the issues resulting from it.

    Just in Windows, Strawberry sees 10-20,000 installations a month, and
    I'm fairly certain you guys do 5 to 10 times that, or more.

    Of that huge bulk, how many are ALSO playing games with cygwin or
    multi-installing? I'd wager not many outside of complicated server
    installations.

    Of all the people using a Linux or BSD distros, how many install
    parallel Perl installs in addition to the core? Again, I'd bet that in
    percentage terms it's small. And the people that do are the ones that
    are more likely to know that they should or can run the installer
    explicitly.

    Given we can also make the extension hooks detect and defend
    themselves against multiple-installation situations, and that we won't
    LIMIT installation to these convenience measures, I can't see how the
    risks of gotchas to smart people doing complex things would make it
    not worthwhile adding optimisations for naive people doing simple
    things.

    Adam K
  • Adam Kennedy at Apr 15, 2010 at 3:52 pm

    On Thu, Apr 15, 2010 at 11:59 AM, Jesse Vincent wrote:
    I've been meaning to propose for a while that for CPAN Perl 5 we drop
    support for everything other than tar.gz (we can talk about the need
    for zip files later) and encourage a switch to something like

    D/DA/DAGOLDEN/Foo-Bar-1.23.cpan
    +1 (reserving the option to bikeshed about the extension)
    -1

    Forcing an extension makes all sorts of tools that previously "just
    worked" with a tarball suddenly start to fail.
    ... which is why I wouldn't be so silly as to suggest it would be the
    exclusive extension or anything else that would break
    back-compatibility. I'm usually the one here arguing FOR additional
    compat.

    The dedicated extension doesn't work as well for Perl 5 as it works
    for Perl 6 (which has the option of starting fresh).

    But if .cpan was just a renamed .tgz it would at least give us the
    extension-hook options at the client end fairly easily without
    changing almost anything anywhere in the current toolchain. In the
    Perl 5 situation you'd by no means forbid regular tarball naming.

    Adam K
  • Jesse Vincent at Apr 15, 2010 at 4:24 pm
    Larry points out that the shibboleth for Perl 6 code is:

    : No package statements. Instead, you'll see "module" statements.

    That ought to be a pretty reasonable way for the indexer to know it's
    Perl 6 code in the absence of other markers. I do think that xdg's plan
    to have an at-upload-time flag for "hey, this is perl 6" which tells
    PAUSE not to even _try_ looking at the tarball as a Perl 5 module makes
    tons of sense.

    And I really like having Perl 6 dists split out into /perl6/ inside an
    author directory. It keeps the author tree together as one coherent
    community while making it really easy for people browsing the hierarchy
    to understand what's what.
    -Jesse
  • Eric Wilhelm at Apr 15, 2010 at 6:29 pm
    # from Jesse Vincent
    # on Thursday 15 April 2010 09:24:
    -1 ... Forcing an extension makes all sorts of tools that
    previously "just worked" with a tarball suddenly start to fail.
    Which tools are going to "just work" on a perl 6 tarball? If it's a
    generic tar tool, it should still just work regardless of the
    extension. If it's assuming a perl5 dist, it is going to fail in
    amazing ways. Then we'll have perl6 authors getting spurious mail from
    bots about how their code doesn't run in perl5?
    # from Tim Bunce
    -1 ... It's also the wrong place to encode version information.
    But perl6 is not a version of perl5.
    Larry points out that the shibboleth for Perl 6 code is:
    : No package statements.  Instead, you'll see "module" statements.
    That requires examining the contents and not just the path, and doesn't
    solve the naming conflict on the CPAN filesystem.
    And I really like having Perl 6 dists split out into /perl6/ inside an
    author directory.
    I really dislike this. Again, tools that assume perl5 dists are going
    to suddenly be assaulted by perl6 dists and it is going to leave us
    with a kludgy mess. Anything that uses `find -name '*.tar.gz'` will
    need special rules to skip perl6 directories.
    It keeps the author tree together as one coherent
    community while making it really easy for people browsing the
    hierarchy to understand what's what.
    I'm all for that, but if we're not going to have a replica of the
    existing tree rooted at /perl6/, then the next best thing would be to
    have a new file extension.

    It's easy enough to add a file extension to existing code which can
    handle perl6 dists, requires no immediate plumbing on PAUSE, and it
    solves the filename conflict between an author's perl5/perl6 dists e.g.
    E/EW/EWILHELM/Foo-Bar-v1.2.0.tar.gz | E/EW/EWILHELM/Foo-Bar-v1.2.0.p6d.

    If we're going to decide that a naming convention is the quick-fix place
    to start, let's use one that isn't going to cause trouble for existing
    tools. The file extension convention has the benefit of also giving
    meaning to the filename outside of the CPAN tree, which opens the
    possibility of having smarter tools later.

    --Eric
    --
    "If you only know how to use a hammer, every problem begins to look like
    a nail."
    --Richard B. Johnson
    ---------------------------------------------------
    http://scratchcomputing.com
    ---------------------------------------------------
  • Eric Wilhelm at Apr 15, 2010 at 7:57 pm
    # from Adam Kennedy
    # on Wednesday 14 April 2010 17:53:
    Alternative option, when we switch to Perl 6 also take the opportunity
    to switch to a specific named extension. +1
    I've been meaning to propose for a while that for CPAN Perl 5 we drop
    support for everything other than tar.gz (we can talk about the need
    for zip files later) and encourage a switch to something like

    D/DA/DAGOLDEN/Foo-Bar-1.23.cpan
    Yes, but it doesn't have to be so much a dropping as an adopting.

    But what is a .cpan file? The CPAN is the archive network, the files on
    it are perl distributions, so .p5d/.p6d seems more appropriate.

    As for zip, bz2, 7zip and such files... they're all bags of bytes last I
    checked.

    --Eric
    --
    Entia non sunt multiplicanda praeter necessitatem.
    --Occam's Razor
    ---------------------------------------------------
    http://scratchcomputing.com
    ---------------------------------------------------
  • Adam Kennedy at Apr 16, 2010 at 12:03 am

    On Fri, Apr 16, 2010 at 5:56 AM, Eric Wilhelm wrote:
    I've been meaning to propose for a while that for CPAN Perl 5 we drop
    support for everything other than tar.gz (we can talk about the need
    for zip files later) and encourage a switch to something like

    D/DA/DAGOLDEN/Foo-Bar-1.23.cpan
    Yes, but it doesn't have to be so much a dropping as an adopting.

    But what is a .cpan file?  The CPAN is the archive network, the files on
    it are perl distributions, so .p5d/.p6d seems more appropriate.
    I'm not at all precious about the specific file extension we use.
    As for zip, bz2, 7zip and such files... they're all bags of bytes last I
    checked.
    The limitation would be to reduce the surface area of the "standard"
    and thus reduce the number of dependencies and level of complexity
    imposed on cpan client implementations.

    Adam K
  • Eric Wilhelm at Apr 16, 2010 at 6:57 am
    # from Adam Kennedy
    # on Thursday 15 April 2010 17:03:
    As for zip, bz2, 7zip and such files... they're all bags of bytes
    last I checked.
    The limitation would be to reduce the surface area of the "standard"
    and thus reduce the number of dependencies and level of complexity
    imposed on cpan client implementations.
    If you want the standard to ever evolve, the client must check the file
    header (and most decompression tools will anyway) so that it can know
    when it gets a file it can't handle.

    --Eric
    --
    So malloc calls a timeout and starts rummaging around the free chain,
    sorting things out, and merging adjacent small free blocks into larger
    blocks. This takes 3 1/2 days.
    --Joel Spolsky
    ---------------------------------------------------
    http://scratchcomputing.com
    ---------------------------------------------------

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-workers @
categoriesperl
postedApr 13, '10 at 5:48p
activeApr 16, '10 at 6:57a
posts38
users13
websitecpan.org

People

Translate

site design / logo © 2021 Grokbase