…uilds

This is for example for runviewer, which has cython as a build-timde
dependency. And setuptools_scm as a build-time dependency should not be
a special case (other than the fact that we want to use a git version of
it). This patch solves that problem for now, but read onward for a
discussion and alternate solutions.

Set `--no-build-isolation` in the manylinux action, because it uses `pip
wheel` to build the wheels, and the mere existence of a `pyproject.toml`
(used here solely for configuring `black`, see
psf/black#683) causes pip to build the wheels
in an isolated environment, devoid of our actual build dependencies
since we are not declaring build dependencies in `pyproject.toml` as
this new PEP 517/518 mechanism (that introduced `pyproject.toml`) would
have us do.

Actually abandoning `setup_requires` (the contents of which there exists
no mechanism to automatically install without running setup.py first -
other than parsing `setup.cfg` ourselves as is done here) and putting
build dependencies in `pyproject.toml` is another option. However, this
will prevent us from injecting additional build-time dependencies like
we are doing with `setuptools_scm`. We could list the git version of
`setuptools_scm` as a build-time dependency in `pyproject.toml`, but
conda won't understand that - at the moment we're just hackily
pip-installing the git version of `setuptools_conda` in the conda
environment (just realising now this probably only works for the
`--from-wheel` packages - otherwise packages are built also in an
isolated environment where they won't see our hackily installed
`setuptools_scm`. I bet those packages will have the wrong version!
Bleh.).

Once `setuptools_scm` releases with the `release-branch-semver` scheme
(they released yesterday, but alas in their own migration from
`setup.py` to `setup.cfg` they didn't migrate the new scheme!
pypa/setuptools-scm#441), this is probably moot
and we could declare build dependencies in `pyproject.toml` - I don't
imagine we'll be using git versions of build dependencies very often.
Then pip could build wheels for us in accordance with PEP 517 without us
having to install build dependencies ourselves at all.

However the bootstrapping issue for `setuptools_conda` will remain - how
will it know that you need to install `cython` in order to run
`setup.py`, when no `setuptools_conda` code runs until you're already
running `setup.py`? It will presumably require an external tool to let
you say:
```bash
$ setuptools_conda dist_conda . [args]
```
instead of
```bash
$ python setup.py dist_conda [args]
```

so that it has a chance to parse some `toml` and install the
build-dependencies before running `setup.py`.

…uilds

This is for example for runviewer, which has cython as a build-timde
dependency. And setuptools_scm as a build-time dependency should not be
a special case (other than the fact that we want to use a git version of
it). This patch solves that problem for now, but read onward for a
discussion and alternate solutions.

Set `--no-build-isolation` in the manylinux action, because it uses `pip
wheel` to build the wheels, and the mere existence of a `pyproject.toml`
(used here solely for configuring `black`, see
psf/black#683) causes pip to build the wheels
in an isolated environment, devoid of our actual build dependencies
since we are not declaring build dependencies in `pyproject.toml` as
this new PEP 517/518 mechanism (that introduced `pyproject.toml`) would
have us do.

Actually abandoning `setup_requires` (the contents of which there exists
no mechanism to automatically install without running setup.py first -
other than parsing `setup.cfg` ourselves as is done here) and putting
build dependencies in `pyproject.toml` is another option. However, this
will prevent us from injecting additional build-time dependencies like
we are doing with `setuptools_scm`. We could list the git version of
`setuptools_scm` as a build-time dependency in `pyproject.toml`, but
conda won't understand that - at the moment we're just hackily
pip-installing the git version of `setuptools_conda` in the conda
environment (just realising now this probably only works for the
`--from-wheel` packages - otherwise packages are built also in an
isolated environment where they won't see our hackily installed
`setuptools_scm`. I bet those packages will have the wrong version!
Bleh.).

Once `setuptools_scm` releases with the `release-branch-semver` scheme
(they released yesterday, but alas in their own migration from
`setup.py` to `setup.cfg` they didn't migrate the new scheme!
pypa/setuptools-scm#441), this is probably moot
and we could declare build dependencies in `pyproject.toml` - I don't
imagine we'll be using git versions of build dependencies very often.
Then pip could build wheels for us in accordance with PEP 517 without us
having to install build dependencies ourselves at all.

However the bootstrapping issue for `setuptools_conda` will remain - how
will it know that you need to install `cython` in order to run
`setup.py`, when no `setuptools_conda` code runs until you're already
running `setup.py`? It will presumably require an external tool to let
you say:
```bash
$ setuptools_conda dist_conda . [args]
```
instead of
```bash
$ python setup.py dist_conda [args]
```

so that it has a chance to parse some `toml` and install the
build-dependencies before running `setup.py`.

…uilds

This is for example for runviewer, which has cython as a build-timde
dependency. And setuptools_scm as a build-time dependency should not be
a special case (other than the fact that we want to use a git version of
it). This patch solves that problem for now, but read onward for a
discussion and alternate solutions.

Set `--no-build-isolation` in the manylinux action, because it uses `pip
wheel` to build the wheels, and the mere existence of a `pyproject.toml`
(used here solely for configuring `black`, see
psf/black#683) causes pip to build the wheels
in an isolated environment, devoid of our actual build dependencies
since we are not declaring build dependencies in `pyproject.toml` as
this new PEP 517/518 mechanism (that introduced `pyproject.toml`) would
have us do.

Actually abandoning `setup_requires` (the contents of which there exists
no mechanism to automatically install without running setup.py first -
other than parsing `setup.cfg` ourselves as is done here) and putting
build dependencies in `pyproject.toml` is another option. However, this
will prevent us from injecting additional build-time dependencies like
we are doing with `setuptools_scm`. We could list the git version of
`setuptools_scm` as a build-time dependency in `pyproject.toml`, but
conda won't understand that - at the moment we're just hackily
pip-installing the git version of `setuptools_conda` in the conda
environment.

Once `setuptools_scm` releases with the `release-branch-semver` scheme
(they released yesterday, but alas in their own migration from
`setup.py` to `setup.cfg` they didn't migrate the new scheme!
pypa/setuptools-scm#441), this is probably moot
and we could declare build dependencies in `pyproject.toml` - I don't
imagine we'll be using git versions of build dependencies very often.
Then pip could build wheels for us in accordance with PEP 517 without us
having to install build dependencies ourselves at all.

However the bootstrapping issue for `setuptools_conda` will remain - how
will it know that you need to install `cython` in order to run
`setup.py`, when no `setuptools_conda` code runs until you're already
running `setup.py`? It will presumably require an external tool to let
you say:
```bash
$ setuptools_conda . dist_conda [args]
```
instead of
```bash
$ python setup.py dist_conda [args]
```

so that it has a chance to parse some `toml` and install the
build-dependencies before running `setup.py`.