pause
pause copied to clipboard
andk
Failed PAUSE indexer report for dmake distribution
I received a failed indexer report for dmake-4.12.2-20140329-SHAY.zip at Sat Mar 29 20:35:10 2014 UTC saying "This distribution name can only be used by users with permission for the package dmake, which you do not have."
Can anyone explain why this upload has failed to index?
I have uploaded binary builds of the dmake program (used by MinGW/gcc users to build perl and CPAN modules) numerous times before and never had this trouble. According to peek_perms it's not a case of someone else owning 'dmake' now, although I don't seem to own it either:
https://pause.perl.org/pause/authenquery?pause99_peek_perms_by=me&pause99_peek_perms_query=dmake&pause99_peek_perms_sub=Submit says 'No records found.'
Perl's own README.win32 references the CPAN upload of dmake:
http://perl5.git.perl.org/perl.git/blob/HEAD:/README.win32#l107
so it would be nice to be able to upload a new version.
Andreas has suggested that perhaps it was never indexed (and doesn't need to be since it isn't a module) but never previously emailed to say so, so all I'm seeing here is improved error reporting.
However, previous versions have appeared on http://search.cpan.org, e.g.:
http://search.cpan.org/~shay/dmake-4.12-20090907-SHAY/
whereas my latest upload has not appeared at all.
What do I (now) need to do to make this possible for me?
FWIW, your upload does appear on metacpan: https://metacpan.org/release/SHAY/dmake-4.12.2-20140329-SHAY
For the record, the ticket that changed the permission structures was https://github.com/andk/pause/pull/80. The grandfathering list was https://gist.github.com/rjbs/9567098 and it does not contain dmake.
I'm surprised that http://search.cpan.org/search?query=SHAY&mode=author is not showing the new upload of dmake-4.12.2-20140329-SHAY.
Perhaps releases without any .pm files were omitted since they aren't indexed anyway? I suppose @rjbs would know.
On Mon, Mar 31, 2014 at 11:35 PM, Thomas Sibley [email protected]:
Perhaps releases without any .pm files were omitted since they aren't indexed anyway?
I suspect the indexer fails early because of the permissions issue and never realizes that there are no .pm files.
And I suspect that as Tom said, we did not find it for the grandfathering because it was never indexed.
The broader point is what to do about archive files without modules. It seems like they can be ignored entirely.
David
David Golden [email protected] Twitter/IRC: @xdg
Thanks for pointing out that it's on metacpan.org. I hadn't realized that, since searching for "dmake" on the home page doesn't find it... :-/
I also hadn't realized that it's kind-of on search.cpan.org too (well, actually on www.cpan.org, but a search.cpan.org link gets you there):
http://search.cpan.org/CPAN/authors/id/S/SH/SHAY/dmake-4.12.2-20140329-SHAY.zip http://www.cpan.org/authors/id/S/SH/SHAY/dmake-4.12.2-20140329-SHAY.zip
It's almost the same problem as metacpan.org in that searching doesn't find it, only slightly worse in this case because searching does find previous versions.
Here's a concrete idea: unless a distribution contains either a META file or contains .pm modules in the root or in lib/, then we skip the indexing step even before the name permissions check.
I also realized that something like dmake could include a META file with a 'provides' field claiming the namespace 'dmake' and then someone could install dmake as "cpan dmake" instead of having to refer to the full tarball name to get it. Even though there is no dmake.pm file, indexing is just an association of a namespace to a tarball, after all.
If a dist has no $pmfiles, it is not indexed and no report is generated. See lib/PAUSE/dist.pm +549.
$pmfiles is all the files from ExtUtils::Manifest::manifind() that end in .pm
This check occurs in mail_summary which is currently, on that code path, called after the permissions check.
FTR, Steve has received a report:
The following report has been written by the PAUSE namespace indexer.
Please contact [email protected] if there are any open questions.
User: SHAY (Steve Hay)
Distribution file: dmake-4.12.2-20140329-SHAY.zip
Number of files: 127
*.pm files: 0
README: dmake/README.TXT
META-File: dmake/META.yml
META-Parser: Parse::CPAN::Meta 1.4404
META-driven index: no
Timestamp of file: Sat Mar 29 20:33:40 2014 UTC
Time of this run: Sat Mar 29 20:35:10 2014 UTC
This distribution name can only be used by users with permission for the
package dmake, which you do not have.
I can see how this message might easily be missed, since most people probably don't scroll to the bottom. I wonder if putting the warning near the top of the message or even adjusting the subject line of the email to indicate that there was en error would encourage people to read the full text of the mail.
The subject line was
Subject: Failed: PAUSE indexer report SHAY/dmake-4.12.2-20140329-SHAY.zip
I've now asked cpansearch to help us find out why the upload does not show up on Steve's page
@steve-m-hay Just to clarify, the reason MetaCPAN's search doesn't find your dmake releases is exactly because they aren't indexed (and indeed have nothing to index). Direct links work because all of CPAN's content is available through MetaCPAN, but the search only includes the latest released versions of indexed packages.
Also, ++ on David's suggestion of skipping permissions check if there's nothing to index.
Adding a META-driven claiming of the "dmake" namespace would be useful for search. It looks like it wouldn't help with installation unless a Makefile.PL was also written to copy the executable and shared data into the user's path somewhere.
Yes, I would certainly welcome a META-driven way to claim "dmake". Installation could possibly work if the dmake.exe program (and its configuration files) were in a scripts/ folder? -- They would normally end up in a location such as C:\perl\bin on Windows then, and that's likely to be on the PATH so might just do the trick :-)
On 3 April 2014 05:31, Thomas Sibley [email protected] wrote:
Also, ++ on David's suggestion of skipping permissions check if there's nothing to index.
Adding a META-driven claiming of the "dmake" namespace would be useful for search. It looks like it wouldn't help with installation unless a Makefile.PL was also written to copy the executable and shared data into the user's path somewhere.
— Reply to this email directly or view it on GitHubhttps://github.com/andk/pause/issues/110#issuecomment-39411847 .
@steve-m-hay You can already do this using https://metacpan.org/pod/CPAN::Meta::Spec#provides, although I realize the spec claims it still requires a dmake.pm file on disk. I don't know if @dagolden was suggesting that requirement change.
I believe in Lancaster we agreed that the 'file' has to be the "source" of the namespace claim, not a literal .pm file, and that one could name the META.json file itself if the source of the package claim is purely metadata.
Having a Makefile.PL that could install it would be cool.
On Thu, Apr 3, 2014 at 11:57 AM, Thomas Sibley [email protected]:
@steve-m-hay https://github.com/steve-m-hay You can already do this using https://metacpan.org/pod/CPAN::Meta::Spec#provides, although I realize the spec claims it still requires a dmake.pm file on disk. I don't know if @dagolden https://github.com/dagolden was suggesting that requirement change.
— Reply to this email directly or view it on GitHubhttps://github.com/andk/pause/issues/110#issuecomment-39469019 .
David Golden [email protected] Twitter/IRC: @xdg
That would mean the metadata fragment would look like:
"provides" : { "dmake" : { "file" : "Makefile.PL", "version" : ..., }, other modules here..., },
If you are not using any distribution builder tools, the way to add this is via WriteMakefile(..., META_MERGE => { provides => ... }) in Makefile.PL.
On Thu, Apr 03, 2014 at 12:18:21PM -0700, David Golden wrote:
I believe in Lancaster we agreed that the 'file' has to be the "source" of the namespace claim, not a literal .pm file, and that one could name the META.json file itself if the source of the package claim is purely metadata.
Having a Makefile.PL that could install it would be cool.
David, would you accept a doc patch for CPAN::Meta::Spec that clarified the Lancaster consensus?
Karen, there's no Makefile.PL currently, just a hand-rolled META.yml. Steve, that'd make the fragment:
provides:
dmake:
file: "META.yml"
version: ...
Do I need a 'version' in the top-level of the META.yml file, or in the dmake section, or both?
I.e. Which of these?:
name: dmake license: gpl provides: dmake: file: META.yml version: 4.12.2-20140403-SHAY
name: dmake license: gpl provides: dmake: file: META.yml version: 4.12.2-20140403-SHAY
name: dmake license: gpl provides: dmake: file: META.yml version: 4.12.2-20140403-SHAY version: 4.12.2-20140403-SHAY
I will look into making the file Makefle.PL and having that actually install dmake into perl's bin, but I don't have time right now. (Using WriteMakefile() could create a META.yml when I'm packaging the distro, but would be of no use to the end-user -- the usual "perl Makefile.PL && [dn]make" obviously won't work if they don't currently have a make program, so I'd have to write some custom code in Makefile.PL so that *it does the installation, or else go down the Module::Build road, which I'm not sure is a great direction to head in right now...)
On 3 April 2014 20:48, Thomas Sibley [email protected] wrote:
David, would you accept a doc patch for CPAN::Meta::Spec that clarified the Lancaster consensus?
Karen, there's no Makefile.PL currently, just a hand-rolled META.yml. Steve, that'd make the fragment:
provides: dmake: file: "META.yml" version: ...
— Reply to this email directly or view it on GitHubhttps://github.com/andk/pause/issues/110#issuecomment-39496322 .
@steve-m-hay Use the third form. CPAN::Meta::Spec claims top-level version is required and also that version under any provides entry is required.
I'm not sure why we're harassing Andreas with this on the ticket, but, oh, well.
The version needs to be a valid perl version that increments normally as the distribution is updated. Unfortunately, "4.12.2-20140403-SHAY" is not going to work.
Steve, do you want to jump onto #toolchain on IRC sometime? The people there (sometimes even me) can help you figure out the best way to do this.
David
On Thu, Apr 3, 2014 at 4:18 PM, Thomas Sibley [email protected]:
@steve-m-hay https://github.com/steve-m-hay Use the third form. CPAN::Meta::Spec claims top-level version is requiredhttps://metacpan.org/pod/CPAN::Meta::Spec#version1and also that version under any provides entry is required.
— Reply to this email directly or view it on GitHubhttps://github.com/andk/pause/issues/110#issuecomment-39499550 .
David Golden [email protected] Twitter/IRC: @xdg
If I have to choose a version from amongst the formats given here:
http://search.cpan.org/~dagolden/CPAN-Meta-2.140640/lib/CPAN/Meta/Spec.pm#Version_Formats
then versions like v4.12.2.1, v4.12.2.2 etc are the only things that will work to represent new builds of dmake-4.12.2. This is the sort of numbering scheme used by Strawberry Perl, so that seems like a good choice anyway.
Thanks for the help with this. I will upload a new version shortly and see what happens.
On 3 April 2014 21:31, David Golden [email protected] wrote:
I'm not sure why we're harassing Andreas with this on the ticket, but, oh, well.
The version needs to be a valid perl version that increments normally as the distribution is updated. Unfortunately, "4.12.2-20140403-SHAY" is not going to work.
Steve, do you want to jump onto #toolchain on IRC sometime? The people there (sometimes even me) can help you figure out the best way to do this.
David
On Thu, Apr 3, 2014 at 4:18 PM, Thomas Sibley [email protected]:
@steve-m-hay https://github.com/steve-m-hay Use the third form. CPAN::Meta::Spec claims top-level version is required< https://metacpan.org/pod/CPAN::Meta::Spec#version1>and also that version under any provides entry is required.
— Reply to this email directly or view it on GitHub< https://github.com/andk/pause/issues/110#issuecomment-39499550> .
David Golden [email protected] Twitter/IRC: @xdg
—
Reply to this email directly or view it on GitHubhttps://github.com/andk/pause/issues/110#issuecomment-39501045 .
Version 4.12.2.2 indexed successfully and now shows up in searches on both search.cpan.org and metacpan.org.
I still don't understand why the previous upload failed to index as before. I will leave this issue open in case anyone wants to pursue that to understand what went wrong, but otherwise I'm happy now and I don't expect to have any trouble with 4.12.2.3 or 4.13.1.1 or whatever is next :-)
Thanks again for the help.