Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Add metadata to identify pure perl and XS distributions #83

Open
melo opened this Issue Jun 15, 2011 · 13 comments

Comments

Projects
None yet
8 participants

melo commented Jun 15, 2011

This would be useful information to have on the distribution page.

Member

monken commented Jun 16, 2011

Hi,

is it enough to look for XSLoader as dependency? I don't know much about XS, so please enlighten me :)

melo commented Jun 16, 2011

I don't know either :), I'll try and find out.

daxim commented Jul 20, 2011

http://deps.cpantesters.org/ shows whether a module is not pure-perl. The criteria are explained in A Brief Note on Purity warnings, the source implementing this is somewhere in http://www.cantrell.org.uk/cgit/cgit.cgi/cpandeps/.

Owner

oalders commented Oct 8, 2014

@pjcj Is this something that cpancover.com could provide? This would be along the lines of the deps discussion we had elsewhere.

Contributor

pjcj commented Oct 11, 2014

cpancover.com could fairly easily say whether or not any C or XS code was executed during the coverage run of the module. But, as with the deps discussion, that would relate only to the actual runs on the cpancover.com server. It's quite possible that a module with a part that would be either XS or pure perl was run with just the pure perl part on cpancover. Then that module would be reported as pure perl. So I'm not sure whether that would be an improvement on the cpantesters heuristics. I suspect not. Though, I suppose it could find modules which use C that cpantesters hadn't found.

If this is thought to be sufficiently useful I'd be happy to add a field to the json file. But I would imagine that getting the data from cpantesters would be the better bet.

Owner

oalders commented Dec 17, 2014

@DrHyde, where we would find this logic in https://github.com/DrHyde/CPANdeps ?

DrHyde commented Dec 17, 2014

https://github.com/DrHyde/CPANdeps/blob/master/lib/CPANdeps.pm#L469 and the next few lines.

The heuristic is that it's not pure-perl if there's a .swg, .xs, .c, .h, or .i file in the MANIFEST and there's no file with 'PurePerl' in its name, or if it depends on any Inline::* module. The MANIFEST parser is somewher, errm, naive.

Owner

oalders commented Dec 17, 2014

@neilbowers can you think of an existing tool on CPAN where we should add this functionality or do you think it would be better as its own module? Maybe Parse::LocalDistribution?

DrHyde commented Dec 17, 2014

I already have a dist that grovels over the contents of a tarball, mostly bard on PAUSE code. That would probably be an appropriate place.

Owner

oalders commented Dec 17, 2014

@DrHyde great. Which dist is this?

Contributor

neilb commented Dec 17, 2014

@oalders Module::Inspector is my first thought, also maybe Module::ParseDeps. I think the former is probably the most appropriate place.

DrHyde commented Dec 18, 2014

@oalders sorry, I was on my phone and looking it up would have been a pain in the arse. https://metacpan.org/pod/CPAN::ParseDistribution

Contributor

kentfredric commented Jan 11, 2015

I've proposed some metadata extensions Perl-Toolchain-Gang/CPAN-Meta#82 which would (among other things) allow CPAN authors to easily and authoritatively state "this dist requires a compiler", so that if such a field is present, it can be taken verbatim instead of relying purely on heuristics.

Obviously even once such a mechanism exists it doesn't "solve" this problem, but adds a useful place to override false-positive and false-negative conditions without having to add special cases in whatever the sniffer is.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment