DO NOT MERGE: testing 1.4.3

[stuarteberg]

This PR tests the latest git rev of pyspice, which isn't tagged yet.
See #13

Checklist

• Used a fork of the feedstock to propose changes
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy
• Ensured the license file is being packaged.

[conda-forge-linter]

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.

[stuarteberg]

Here's the status of this test:

1. Linux passes.

2. Mac fails, but it's not a "real" failure. It fails due to some obscure git error related to unicode names. It will not fail in a "real" build, since those don't use a git_url source. (See note below.)

3. Windows fails. Apparently pyspice-post-installation --check-install is failing with no error message -- just a bad exit code. I have no idea why, or even how this can happen without printing an error. I'm at a loss here.

---

Note about the Mac unicode failure:

This problem is not specific to conda-forge. Any Mac user with a recent version of git will encounter the following error when they clone the PySpice repo and run git status:

fatal: iconv_open(UTF-8,UTF-8-MAC) failed, but needed:
    precomposed unicode is not supported.
    If you want to use decomposed unicode, run
    "git config core.precomposeunicode false"

I called git config core.precomposeunicode false as suggested by the error message, and the problem disappeared. I guess all Mac users must do that when cloning PySpice.

What's the cause? Apparently something weird can happen when transferring files with non-ASCII names to/from the Mac filesystem. The PySpice repo contains two files with a non-ascii character (é):

examples/fundamental-laws/m4/thévenin-norton-theorem.m4
examples/fundamental-laws/thévenin-norton-theorem.py

I am not knowledgeable on the subject of "precomposed" vs. "decomposed" unicode, but here are some possible solutions:

• Change those two file names
• Maybe there is some way to fix the repo without changing the file names.
• Add a warning to Mac users in the README

Again, this is not a problem for our conda-forge recipe in general, since we will normally build from a tarball, not from git.

[stuarteberg]

@FabriceSalvaire OK, I fixed the issue on Windows. (It's related to conda/conda-build#3965.)

As mentioned above, the Mac problem is not a "real" problem. So I think this PR demonstrates that we'll be ready to publish conda packages for v1.4.3 whenever you tag it in the PySpice repo.

[FabriceSalvaire]

@stuarteberg looks good ! I got a Windows machine to test ! but must read conda-forge doc ...

[stuarteberg]

I got a Windows machine to test !

Since this is just a PR and has not yet been merged to master, the package is not uploaded to anaconda.org. There is no convenient way to test it.

But I have just rebuilt this recipe locally, and uploaded it to my personal channel for you to test:

conda install -c stuarteberg pyspice=1.4.3b0=pr14_0

I won't be able to do that frequently, but maybe that's enough for a basic evaluation of this recipe so far.