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.

I'm not 💯 % sure that this will fix #58 but I think it will. I guess to test it fully, I'd have to use the built package here to build one of the downstream noarch packages and see that they will work on Windows.

Also @mingwandroid is still a code owner here 😭

@conda-forge-admin, please rerender

@mbargull you might want to take a look at this since you were the last to modify the run_exports.noarch in 9695e1f as a part of #49

My reasoning for this PR was put into the issue at #58 (comment)

we shouldn't specify *_perl5 or *_strawberry in the run_exports.noarch

The problem occurs because noarch packages are only built on linux-64 and pickup the run_exports from the unix perl package and *_perl5 isn't satisfiable on Windows because perl on windows is _strawberry.

This is exactly working as intended.
Unless someone puts in the work to build Perl on Windows from source so that we can align the directory structures on all platforms, we need to have a distinction between builds that have already been built with one or the other layout.
With gh-49 we got at least Windows and macOS packages aligned so that we could have noarch Perl packages (which we couldn't do at all before).
Our Windows packages are still just a repackaging on Strawberry Perl's builds which have another layout.
If we'd drop the *_perl5 build string match, we'd let those noarch packages built for the lib/perl5/... layout install on Windows, but the user wouldn't be able to use the installed packages at all since the repackaged Strawberry Perl doesn't look at the paths they are installed at.
Adding *_perl5/*_strawberry constraints lets us ensure users don't install broken packages.
The problem is that the package manager doesn't give us any facility to say "use can't install the package because of ".

If you'd want certain packages available (on usable!) on Windows, too, you'd need 2 builds:

• one build for noarch which can be use on Linux/macOS,
• another one explicitly for Windows.(ideally without noarch since the Strawberry Perl layout is only used on Windows).

The other/better solution would be to get someone to work on a Windows build with a directory layout we have on the other platforms too (I won't be able to look into this anytime soon, unfortunately).

Also @mingwandroid is still a code owner here 😭

Ray would certainly be someone I would've liked to work with on these pesky Windows issues 😐