Skip Menu |

This queue is for tickets about the Module-Metadata CPAN distribution.

Maintainer(s)' notes

Attention bug reporters: issues MUST include the version of Module::Metadata that you are running that exhibit the stated symptoms. thank you!

Report information
The Basics
Id: 101439
Status: rejected
Priority: 0/
Queue: Module-Metadata
People
Owner: Nobody in particular
Requestors: KENTNL [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: Wishlist
Broken in: 1.000025
Fixed in: (no value)

History Show all quoted text
  Fri Jan 09 22:24:59 2015 KENTNL [...] cpan.org - Ticket created
Subject: wishlist: API to expose even hidden packages

There are cases where a .pm file may lack package statements for the purpose of indexing, but it may be desirable to know about them all the same.

 

This is a similar problem space to the "is_indexable" scope, except I'm at the starting point where I don't know how I'd scan for a given package name being *declared* but also being *intentionally hidden* for the sake of indexing.

 

For instance, I'm doing meta-provides data: I want to be making sure all files have namespaces that should have them, unless the files themselves declare "no, don't index me", because that condition is clear that it is not an error that there is no declared namespace>

https://github.com/kentnl/Dist-Zilla-Plugin-MetaProvides-Package/issues/3

 

Essentially, there's a trinary state:

 

1: A file has no package declarations

2: A file has package declarations but they're intentionally hidden

3: A file has an unhidden package declaration

 

Presently, #2 is seen like #1 and is an error/warning condtion, but I want #2 to be ignored as if it was #3

But the data is not so apparent as to how to do that.

Even with is_indexable, I can't ascertain this, because it appears as if it would treat case #2 as case #1, even if I constructed the expected namespace from the filename.

  Fri Jan 09 22:40:53 2015 ether [...] cpan.org - Correspondence added
On 2015-01-09 19:24:59, KENTNL wrote: Show quoted text
> There are cases where a .pm file may lack package statements for the > purpose of > indexing, but it may be desirable to know about them all the same. > > This is a similar problem space to the "is_indexable" scope, except > I'm at the > starting point where I don't know how I'd scan for a given package > name being > *declared* but also being *intentionally hidden* for the sake of > indexing.
To find a package statement that was "hidden" from Module::Metadata yet visible to perl, I'd use PPI to find it -- it's a pretty simple matter to scan a document for all PPI::Statement::Package nodes.
  Fri Jan 09 22:40:55 2015 The RT System itself - Status changed from 'new' to 'open'
  Fri Jan 09 23:22:32 2015 KENTNL [...] cpan.org - Correspondence added

> To find a package statement that was "hidden" from Module::Metadata
> yet visible to perl, I'd use PPI to find it -- it's a pretty simple
> matter to scan a document for all PPI::Statement::Package nodes.

Perhaps, but it does seem to be the sort of thing that would be "In the scope" of Module::Metadata to provide, and I'm lothe to have to provide a similar module to cover this scope ( becuase obviously, MM can't depend on PPI )

As am I somewhat distrustful about having to have 2 sets of code to scrape the same file for what is essentially the same metadata ± a delta just to ascertain what the delta between them is. Because as easy as that *sounds*, I feel like I'm likely to fuscre it up in some subtle way and have a few iterations on unfuscring it.

 

  Sat Jan 10 18:39:08 2015 karen [...] froods.org - Correspondence added
Subject: Re: [rt.cpan.org #101439] wishlist: API to expose even hidden packages
Date: Sat, 10 Jan 2015 15:38:58 -0800
To: bug-Module-Metadata [...] rt.cpan.org
From: Karen Etheridge <karen [...] froods.org>
We could probably do something like $content =~ /package(\s*#.*$)*\s*$MODULENAME_PATTERN/ to find hidden things. It might be better for your plugin to do that itself though, rather than expose this as a Module::Metadata interface - arguably fom its perspective, if it's hidden, it's unreportable! On Fri, Jan 9, 2015 at 8:22 PM, Kent Fredric via RT < bug-Module-Metadata@rt.cpan.org> wrote: Show quoted text
> Queue: Module-Metadata > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=101439 > >
> > To find a package statement that was "hidden" from Module::Metadata > > yet visible to perl, I'd use PPI to find it -- it's a pretty simple > > matter to scan a document for all PPI::Statement::Package nodes.
> > Perhaps, but it does seem to be the sort of thing that would be "In the > scope" > of Module::Metadata to provide, and I'm lothe to have to provide a similar > module to cover this scope ( becuase obviously, MM can't depend on PPI ) > > As am I somewhat distrustful about having to have 2 sets of code to scrape > the > same file for what is essentially the same metadata ± a delta just to > ascertain > what the delta between them is. Because as easy as that *sounds*, I feel > like > I'm likely to fuscre it up in some subtle way and have a few iterations on > unfuscring it. > >
  Fri Sep 11 00:59:46 2015 ether [...] cpan.org - Correspondence added
On 2015-01-09 20:22:32, KENTNL wrote: Show quoted text
> > To find a package statement that was "hidden" from Module::Metadata > > yet visible to perl, I'd use PPI to find it -- it's a pretty simple > > matter to scan a document for all PPI::Statement::Package nodes.
> > Perhaps, but it does seem to be the sort of thing that would be "In > the scope" > of Module::Metadata to provide, and I'm lothe to have to provide a > similar > module to cover this scope ( becuase obviously, MM can't depend on PPI > )
This is a paradox. You want to find hidden packages, using the very thing that the package is trying to hide from. This is impossible -- a different scanning/parsing mechanism is needed :) I'm sticking with "you should use PPI" (or whatever its successor may be), that parses perl more rigorously. But I could be wrong. Reopen if so.
  Fri Sep 11 00:59:49 2015 ether [...] cpan.org - Status changed from 'open' to 'rejected'