[DBIx-Class-Devel] Pull Request: topic/docs-pod-inherit

[Peter Rabbitson]

On Fri, Dec 14, 2012 at 10:40:27AM -0500, Brendan Byrd wrote:
> On Fri, Dec 14, 2012 at 9:31 AM, Peter Rabbitson <rabbit+dbic at rabbit.us> wrote:
> >
> > POD separation works fine (at least on s.c.o. which is what *I* care
> > about, metacpan can always catch up). It is the dual libdir that
> > confuses it. I am waiting for 0.08204_02 to go through s.c.o.
> > indexing[1], and if it looks fine I'll merge for_current/eumm_taming
> > which contains all the trickery (in particular 374cd092).
> 
> Correct me if I'm wrong, but I can find absolutely nothing in META
> that knows about the libdir structure.  So, it doesn't matter how or
> where it's split up, as SCO/MetaCPAN will simply index anything that
> isn't in no_index.

Yes, but the "indexing" (this is not an entirely correct term, because
it has to do with the PAUSE indexes) is based on filename, not only
on contents.
 
> 1. Separate .generated_pod/lib.  Already tried that.
s.c.o. has problems with that, metacpan is just not yet fixed

> 2. Edit the PM directly.  Don't want to do that.
not a chance

> 3. Combined directory with pod/pm together.  Doesn't change anything.
On the contrary - http://search.cpan.org/~ribasushi/DBIx-Class-0.08204_02/
Now all you need to do is press the metacpan folks to fix their stuff
to match how s.c.o. (correctly) behaves.

The list of issues comparing:
http://search.cpan.org/~ribasushi/DBIx-Class-0.08204_02/ and
https://metacpan.org/release/RIBASUSHI/DBIx-Class-0.08204_02/

* Documentation section has duplicate entries for stuff existing in
the Modules section (a simple exclusion needs to run before compiling
the list of files)
* If a x.pod and x.pm exist, a web UI must link to the .pod, devrel
or no devrel.
* Metacpan puts DBIx::Class::Optional::Dependencies in the Provides
section for no reason (it is a proper .pm, ought to be in Modules)
* DBIx::Class::Carp is in Modules, even though it is explicitly
no_index-ed

> 4. Kill the =NAME from the PM.  Still mods the PM, and may or may not
> work, since SCO/MetaCPAN still tries to "interpret" the PM name.
Correct - it can't be removed

> 5. Add the dupe PMs to no_index.  Might work, but not sure if this
> causes adverse effects to CPAN, installs, and perldoc.
Yes it does - no_index is general for "hide from any search index"

> > Note this does *not yet* contain the $RUNNING_IN_HELL fixups to replace
> > your s/'/"/ (which is very very un-unixy hence bad :) I ran out of tuits
> > to wrap it up, but already identified the EUMM machinery which will make
> > it happen.
> 
> Didn't Matt have a more elegant solution, back when I ran into this
> issue many moons ago?

Not that I know of. My fix is to be based on [1]. There are more parts
to put in place however, which is why I didn't rush it.

[1] https://metacpan.org/module/ExtUtils::MM_Any#oneliner-Abstract

Cheers