Add Perl package hints to documentation

[zklaus]

Recently, @mbargull has updated some Perl parts of conda-forge and in the process simplified the way Perl packages can be built. This was already exploited with good effect by @tdegeus to migrate some Perl packages from bioconda.

Adding the simple packaging instructions to the knowledge base will help new maintainers to add Perl packages in a consistent manner.

[prachinandi]

@zklaus @mbargull I would like to take this issue. From where can I get info on the simple packaging instructions?

[zklaus]

@prachi237, that's great! Thanks a lot. @mbargull and @tdegeus are the experts, but let me try to get you started. Then you can figure out where exactly to place the information, start a PR on it and let us know.

Perl has three standard install locations: core, vendor, and site. For some time, conda-forge was a bit unsure how to do the exact layout of directories, but with conda-forge/perl-feedstock#49, @mbargull set it straight: leave core alone (that's only for perl itself), install conda-forge packages into vendor, and leave site free for the user to install things locally from other sources than conda-forge.

The most commonly used build system for perl packages is ExtUtils::MakeMaker. For the archetypical packaging of packages of this form, you can have a look at perl-file-which's recipe.

Note how:

• the name is composed of perl- + the lowered version of the CPAN name
• the requirements contain make for build, perl and perl-extutils-makemaker for host, and perl for run.
• the tests section under imports lists the CPAN module that can be used in perl

The script should also be identical with

build:
  number: 0
  noarch: generic
  script:
    - perl Makefile.PL INSTALLDIRS=vendor NO_PERLLOCAL=1 NO_PACKLIST=1
    - make
    - make test
    - make install VERBINST=1

where the line with Makefile.PL is the crucial one that guarantees installation into the vendor section as discussed above, as well as non-interference with standard files by the NO_PERLLOCAL and NO_PACKLIST switches.

Note that the noarch: generic should be present only if the package is a pure perl one, i.e. contains no compiled c code or extensions, and that of course more requirements can be necessary.

Thanks again and good luck.

[prachinandi]

Sure thing sir! I will start working on it, in case I face any difficulty in between will let u know. Thanks !!