add perl-compress-bgzf

[jvolkening]

Checklist

• Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml".
• License file is packaged (see here for an example).
• Source is from official source.
• Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).
• If static libraries are linked in, the license of the static library is packaged.
• Package does not ship static libraries. If static libraries are needed, follow CFEP-18.
• Build number is 0.
• A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details).
• GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there.
• When in trouble, please check our knowledge base documentation before pinging a team.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/perl-compress-bgzf) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipes/perl-compress-bgzf:

• Recipe with the same name exists in bioconda: please discuss with @conda-forge/bioconda-recipes.

[jvolkening]

@conda-forge/help-perl Trying to migrate the first of my packages from bioconda, and can't get past this build failure with this package using Module::Build. As far as I can tell, the build goes fine but no files are actually found/packaged. Relevant lines from the build log appear to be:

...
Result: PASS
Building Compress-BGZF                                                                           
Installing $BUILD_PREFIX/lib/perl5/vendor_perl/Compress/BGZF.pm                                  
Installing $BUILD_PREFIX/lib/perl5/vendor_perl/Compress/BGZF/Reader.pm                           
Installing $BUILD_PREFIX/lib/perl5/vendor_perl/Compress/BGZF/Writer.pm                           
Installing $BUILD_PREFIX/man/man3/Compress::BGZF::Writer.3                                       
Installing $BUILD_PREFIX/man/man3/Compress::BGZF::Reader.3                                       
Installing $BUILD_PREFIX/man/man3/Compress::BGZF.3                                               
Installing $BUILD_PREFIX/bin/bgzip.pl                                                            
                                                                                                 
Resource usage statistics from building perl-compress-bgzf:                                      
   Process count: 3                                                                              
   CPU time: Sys=0:00:00.0, User=0:00:00.2                                                       
   Memory: 28.0M                                                                                 
   Disk usage: 1.0K                                                                              
   Time elapsed: 0:00:04.0                                                                       
                                                                                                 
                                                                                                 
Packaging perl-compress-bgzf                                                                     
Packaging perl-compress-bgzf-0.006-pl5321hd8ed1ab_0                                              
WARNING: No files or script found for output perl-compress-bgzf                                  
number of files: 0
...

Any advice? I can't find any other perl-* packages on conda-forge which use Module::Build, but it's not a particularly obscure packager.

[jvolkening]

Looks like @conda-forge/help-perl team is empty, so pinging @conda-forge/perl for any advice on above.

[mfansler]

Not a Perl expert, but looks like it's installing into BUILD_PREFIX instead of PREFIX. Probably shouldn't have perl as a build dependency, but just host (and run). This also would be consistent with what conda skeleton cpan Compress::BGZF generates.

[jvolkening]

Thanks @mfansler, good idea and the recipe built by conda skeleton cpan works. There are some parts of it that I don't think are in line with the latest recommendations, but I was able to compare the differences and narrow the issue down to the inclusion of noarch: generic in the recipe. The conda skeleton cpan does not add this, although my understanding is that it is the correct thing to do for pure-perl packages. If I remove it from my own recipe, the build works. If I add it to the skeleton recipe, it fails. When noarch: generic is included, the actual build succeeds but the tests fail (in this case, only trying to import the modules which can't be found).

What makes this more confusing is that for the existing conda-forge perl recipes, all of which are for packages using the ExtUtils::MakeMaker build system, at least some are marked noarch: generic and it doesn't seem to cause a problem (e.g. perl-text-csv). So, it seems to be specific to the use of Module::Build. In theory, both systems should be installing the files to the same locations.

I just saw that the win64 build failed because perl-module-build is not build for win64. This is another issue that I will ask about on that feedstock (is there any reason to skip Windows build).

EDIT: This was wrong. See comment below.

[mfansler]

"...narrow the issue down to the inclusion of noarch: generic in the recipe. The conda skeleton cpan does not add this, although my understanding is that it is the correct thing to do for pure-perl packages. If I remove it from my own recipe, the build works. If I add it to the skeleton recipe, it fails. When noarch: generic is included, the actual build succeeds but the tests fail (in this case, only trying to import the modules which can't be found)."

I can't replicate this problem. Running the linux-64 build locally on the current recipe with noarch: generic works just fine for me. I'd suggest adding the noarch back here and seeing where it goes. We only need linux-64 to pass.

[jvolkening]

I can't replicate this problem. Running the linux-64 build locally on the current recipe with noarch: generic works just fine for me. I'd suggest adding the noarch back here and seeing where it goes. We only need linux-64 to pass.

Yes, you beat me to it. Maybe my issues were a result of cached build files, but when I removed the build artifacts and re-tried with noarch: generic it worked. More testing suggests that your original comment points to the problem, which is including perl as a build dependency. I've read the "Defining metadata" docs and wish I understood better why this was, but at least it fixes the immediate issue.

Thanks for the help, by the way.

[mfansler]

A couple suggestions, otherwise looks ready!

[mfansler]

Thanks for taking the time to transfer this! ❤️

Feel free to tag me if any other Bioconda transfers need a review or troubleshooting.

[jvolkening]

@mfansler Thanks again for your guidance. This was one of a few "test runs" I'm doing to help me understand the nuances of conda-forge, but I have plans to try to do more of a "bulk" migration as I become more comfortable. I have opened up an issue here to collect notes related to issues/questions I run into, so that I can use best practices out of the gate. If you have any guidance on the points in that post, hopefully I can understand/fix some of these things locally before opening up more PRs.