add python-ghostscript package

[akrherz]

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.

See conda-forge/camelot-py-feedstock#25 for the need for this package. There is some ambiguity though, as pypi has python3-ghostscript version 0.5, but points to gitlab, which has a version 0.6, but is named python-ghostscript

[conda-forge-webservices]

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 (recipes/python-ghostscript) and found some lint.

Here's what I've got...

For recipes/python-ghostscript:

• noarch: python recipes are required to have a lower bound on the python version. Typically this means putting python >=3.6 in both host and run but you should check upstream for the package's Python compatibility.

For recipes/python-ghostscript:

• License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

[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/python-ghostscript) and found it was in an excellent condition.

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

For recipes/python-ghostscript:

• License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

[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/python-ghostscript) and found it was in an excellent condition.

[akrherz]

I've now found a 0.7 release within the gitlab repo and updated the PR accordingly.

[akrherz]

Eh, I am unsure how important it is that the windows CI fails on a noarch package?

[akrherz]

Yeah, I had better figure out a way to fix this prior to merging

RuntimeError: Can not find Ghostscript DLL in registry

[akrherz]

oOo, green :) a gentle pin to @ocefpaf to see if he has thoughts on what I did here :)

[akrherz]

Now I realize that having OS specific selectors on the patch won't work for a noarch feedstock. So carrying both patches shouldn't be of too much concern.

• windll_path.patch only touches a code path used on windows
• win_version.patch hard codes the version number, which is brittle/dangerous for the next release, but will engage upstream on this.