MSVC complex values

[alugowski]

Implementation of approach as discussed in #64

The core is in a get_extension() method in build.py. It sets up _graphblas as a regular extension rather than a cffi extension. It emits _graphblas.c with emit_c_code() then sets the needed compiler configs. The salient part, converting double _Complex to _Dcomplex and _Fcomplex on MSVC, is done here too. I'm assuming "Windows" == "MSVC".

I moved build.py up a directory to work around an import problem.
suitesparse_graphblas/__init__.py imports a bunch of extensions, such as utils, which don't exist at setup time.
I don't know how to import build.py while skipping __init__.py, so I just moved it up instead.

You'll have to ignore the linter error. It wants a change that will break the imports. The # noqa: E402 would satisfy most linters that this is an ok exception, but apparently not this linter.

Fixes #64

[alugowski]

As per conversation, this also no longer uses the arm header. Please verify that that's acceptable.

[alugowski]

Figured out how to make the linters happy.

[eriknw]

This looks pretty good. I have a couple minor suggestions:

• Can we rename build.py to something else such as buildcffi.py or whatever makes sense? I worry about conflicting with build.
• Let's add build.py (or what it gets renamed to) to MANIFEST.in so the sdist will be able to compile correctly.

I'm sorry I wasn't able to help you earlier with the linting. Of the current linting rules, I think the need to do

import foo  # noqa: E402 isort:skip

is probably the most annoying. Should we add a note somewhere that shows how to ignore linting rules? I would use E402 as the example since it also shows isort. Where would you have found this note? In linting.yml GitHub Action?

I'm going to try testing this (and the wheels in #66) in python-graphblas CI 🤞

[eriknw]

Success!!!!!!! 🎉

See: python-graphblas/python-graphblas#386
Our tests exercise complex dtypes pretty well.

✨👯‍♀️🎊👯✨

@alugowski you're my hero

[eriknw]

As per conversation, this also no longer uses the arm header. Please verify that that's acceptable.

Confirmed 👍

[alugowski]

This looks pretty good. I have a couple minor suggestions:

* Can we rename `build.py` to something else such as `buildcffi.py` or whatever makes sense? I worry about conflicting with [`build`](https://pypi.org/project/build/).

* Let's add `build.py` (or what it gets renamed to) to `MANIFEST.in` so the sdist will be able to compile correctly.

Done. I used "build_graphblas_cffi" because my Java years drilled over-expressiveness into me :P

I'm sorry I wasn't able to help you earlier with the linting. Of the current linting rules, I think the need to do

import foo  # noqa: E402 isort:skip

is probably the most annoying. Should we add a note somewhere that shows how to ignore linting rules? I would use E402 as the example since it also shows isort. Where would you have found this note? In linting.yml GitHub Action?

That particular line is a special case, I don't think it needs a writeup. It's special because it's doing something weird that in general is not needed. Also it's breaking two rules (imports not in alphabetical order, and statement before import), each discovered by a different linter. I'm also open to suggestions about how else to do it, this is all I could think of.

In general it's probably a bad idea to have people defeat the linter instead of following the rules. I did my fair share of cursing at this particular linter's demands, but it basically tells you what it wants so it's not an issue. The cursing is only because its standards are different than PyCharm's and forces a few round trips until all the issues are fixed.

[eriknw]

Thanks for renaming.

@alugowski do you think this is ready to merge (once CI passes)? LGTM.

[alugowski]

Thanks for renaming.

@alugowski do you think this is ready to merge (once CI passes)? LGTM.

Yes, I think so.

[eriknw]

This is in! 🚀