search

conda-forge / perl-feedstock

A conda-smithy repository for perl.
BSD 3-Clause "New" or "Revised" License
3 stars 32 forks source link

New directory layout lib/perl5/... #49

Closed mbargull closed 3 years ago

mbargull commented 3 years ago

Checklist

Addresses the non-Windows part of gh-48.

conda-forge-linter commented 3 years ago

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

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

conda-forge-linter commented 3 years ago

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 (recipe) and found it was in an excellent condition.

mbargull commented 3 years ago

Copying comment over from https://github.com/conda-forge/perl-feedstock/issues/48#issuecomment-732159738:

How about perl extension modules? Are they compatible?

AFAIUI, those are the ones that go into the "archlib" directories, e.g., currently $PREFIX/lib/5.32.0/x86_64-linux-thread-multi, $PREFIX/lib/site_perl/5.32.0/x86_64-linux-thread-multi. With the layout from gh-49 they go into $PREFIX/lib/perl5/core_perl/5.32, $PREFIX/lib/perl5/site_perl/5.32 (as they should be compatible within the same minor Perl version, cf. https://github.com/Perl/perl5/blob/v5.32.0/INSTALL#L2444). By omitting the x86_64-linux-thread-multi part, we can have the same directory structure between different operating systems.

Non-compiled packages previously went into $PREFIX/lib/5.32.0, $PREFIX/lib/site_perl/5.32.0. In gh-49 they are at $PREFIX/lib/perl5/core_perl, $PREFIX/lib/perl5/site_perl and could be used for perl packages with different minor versions, cf. https://github.com/Perl/perl5/blob/v5.32.0/INSTALL#L97.

Overall, we can do away with the initial 5.32.0 directory and the x86_64-linux-thread-multi arch part because we don't support > installing multiple Perl versions or different arches alongside each other.

gh-49 should lay the groundwork for future packaging schemes. If the review goes well and we merge it, we can relax our pinning from major.minor.patch to major.minor.* *_perl5 (on Linux/macOS at least). For future noarch: generic packages or generally packages without extension modules that don't need the minor version pinned, we may have to create some helper packages to ensure the correct pinnings and no files in the perl5/*/5.* paths. If someone wants to work on this, please do! I won't be able to get to this in the near future.

Also, there is this site and vendor split. Maybe we should recommend using the vendor target for our packages -- with perl Makefile.PL INSTALLDIRS=vendor or something a long those lines -- before someone starts to port over all those packages from Bioconda.

mbargull commented 3 years ago

I've enables artifacts storage for this one. Anyone who wants to review (e.g., to try out building some Perl packages with this) can download the built packages at https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=243722&view=artifacts&pathAsName=false&type=publishedArtifacts

mbargull commented 3 years ago

@conda-forge/core , please review. (Unless approved or merged before, I'll merge soon if no veto is given.) I'd like to at least get an approval for the meta.yaml changes (run_exports scheme). Major changes are: libperl.a -> libperl.so; lib/{,X.Y.Z}/{,site_perl} -> lib/perl5/{,X.Y}/{core_perl,vendor_perl,site_perl} (I'll open a conda-build PR to change --installdirs=vendor as the default so that all our perl-* packages go into lib/perl5/*/vendor_perl). (I tried this out with https://github.com/conda-forge/perl-sys-cpu-feedstock and it builds fine.)