I’m thinking about creating a generic package builder that supports both PEP 517 and legacy projects. But I want to be able to run the builder “out of band” i.e. the package may be built against a different interpreter than the one running the tool. Both PackageBuilder and IsolatedEnvironment seem to be very well implemented and modulised (much kudos) to make this possible, and my plan is to subclass and override limited parts of them. But would this be a supported usage going forward, or should I expect things to break (like pip’s implementation)?

I personally only make upper case content that's a paragraph and ends with a period. Github actions don't tend to end with a period so my vote is under making them lower case.

See https://github.com/FFY00/python-build/pull/49#discussion_r444978340

I notice that this is invoked with python -m build. I think it would be a good idea to add python-build or pybuild or something of that nature as an entry point.

The reason that I think this is a good idea is that pipx can only install command line tools that expose entry points, and this is the kind of tool I'd want available via pipx (though probably in any production use I'd be running it in a CI job or something that won't go via pipx).

pyenv brings with it the python-build tool, which it uses to build python versions from source.

Now I've done pip install build, pyenv invokes this python-build, and breaks 😢

Maybe python-build could ship only for invoking as python -m build? This would have the advantage of always knowing which python binary you were invoking (the same reason pip recommends using python -m pip everywhere).

Or maybe pyenv could be convinced to change to pyenv-python-build or similar, though probably breaking some peoples' install scripts?

Should we run mypy via a tox/nox env, or via a pre-commit hook https://github.com/pre-commit/mirrors-mypy?

Such as .tox, which usually takes a long time to copy on Windows.

Code here: https://github.com/FFY00/python-build/blob/b805ff79227d7d72057068e292ab10af6861fcb6/src/build/env.py#L116

Docs for ignore callable kwarg here: https://docs.python.org/3/library/shutil.html#shutil.copytree

Am I missing something, or is prepare_metadata_for_build_wheel() not implemented?

It seems like it's something that isn't specified in PEP-517, but I was of the impression, that metadata hook is a mandatory call for the frontend, which will call that hook before build_wheel(), if available. After all, it's not up to the build frontend whether metadata is needed, the responsibility for that decision lies on the code that actually builds the distribution.

Am I correct in my interpretation of the spec?

It seems that when constructing the isolated environment, python-build still uses the packages in the outer environment if they are present, rather than installing into a "clean" environment.

One consequence of this is that if you have an older version of your build backend in the environment that contains python-build, pip install won't install an upgraded version of it. For example, construct a project with a pyproject.toml like so:

[build-system]
requires = ["setuptools", "wheel"]
build-backend = "setuptools.build_meta"

And a virtualenv like so:

virtualenv venv --no-wheel
source venv/bin/activate
pip install build==0.0.4
pip install setuptools==39.0.0

When you run python-build -w ., when satisfying setuptools, pip will not upgrade setuptools, since it is "already satisfied":

Requirement already satisfied: setuptools in ./venv/lib/python3.8/site-packages (from -r /tmp/build-reqs-r6nyhzz2.txt (line 2)) (39.0.0)

Preferably, pip would consider the isolated environment a blank slate, and you'd get the latest setuptools, unless --no-isolation is passed.

This is not only a problem with pip — the build environment used contains all the packages from the environment python-build was invoked in, as you can see if you create a setup.py like so:

import setuptools

try:
    import dateutil
    raise Exception("dateutil should not be present during isolated builds!")
except ImportError
    print("dateutil not found")

setuptools.setup()

If you run this in the virtualenv we created above, it will succeed and print the "dateutil not found" message. If you then run pip install python-dateutil in the virtualenv, the python-build -w . will fail, indicating that the build is being carried out in an environment not isolated from the base environment.

These results on Arch Linux using virtualenv==20.0.26, build==0.0.4 and Python version 3.8.2 (via pyenv). I have not attempted to replicate this without a virtualenv.

build 0.0.4 uses ensurepip to ensure pip before installing build dependencies:

https://github.com/FFY00/python-build/blob/b805ff79227d7d72057068e292ab10af6861fcb6/src/build/env.py#L169

However, CPython provided by Debian does not include this module and replaces it by a script that always return 1. I suppose we could either:

1. Let pip be a dependency for build
2. Skip ensurepip entirely and let the execution of pip fail if it doesn't exist

Splitting out a comment made by by @FFY00 into it's own issue from https://github.com/FFY00/python-build/issues/106 as it's out of scope therem, but I think we should very much do this (at some point - not release blocker):

I think the environment where we bootstrap pip into could actually be semi-permanent and shared between all builds. This would speed up isolated builds.

Strongly agree 👍

Considering our version support strategy going forward, I was wondering if it might make sense for us to start trying to at least partially decouple the version of Python used to run build and the version of Python used to actually do the build. Similar to the way that virtualenv takes a -p option. This would allow us to drop support for installing python-build in Python 2.7 or other older versions of Python even before we are comfortable dropping support for using build to build packages _targeting _ those versions, because end users could do, e.g. python-build -p python2.7.

This might conflict somewhat with #103, because venv does not have support for cross-interpreter builds (though we may be able to work around that easily enough).

https://github.com/FFY00/python-build/blob/360966b687c15d8357ba98f9e194ff0f877ce3f2/build/__init__.py#L62-L64

This doesn't do what it looks like it does. metadata.get_all merely checks to see if the project's PKG-INFO declares that such an extra exists. It doesn't check to see if the extra is enabled due to having all the required dependencies.

Instead, distribution(''....').requires should be used to recursively retrieve dependencies one level deeper, and all dependencies which are associated with the desired extra should be checked as well.

Using build==0.0.4, it appears that the python-build command must be activated in an environment where the build backend is already installed! As an example, creating a project with a pyproject.toml like this:

[build-system]
requires = ["setuptools", "wheel"]
build-backend = "setuptools.build_meta"

Then touch setup.cfg, and create a virtualenv like so:

virtualenv venv --no-setuptools --no-wheel
source venv/bin/activate
pip install build==0.0.4

Now when you invoke python-build -w ., you'll get:

$ python-build .
ERROR Backend 'setuptools.build_meta' is not available

I think the issue is that ProjectBuilder checks the existence of the build backend, but in __main__ it is constructed before the environment is built.

I'll note that you can build a wheel just fine from an environment where setuptools but not wheel is installed, but if setuptools isn't installed ahead of time, it will cause problems.

This problem is related to but distinct from #97.

I think this definitely needs an integration test.

Opening a new issue to replace #52.

Per the discussion in #18, the current set of tests is not really adequate to give us strong confidence in the robustness of the implementation. Before actually releasing the next version, we need to improve the test suite, specifically:

• Isolated builds should happen in python environments with no packages installed (not even setuptools and wheel).
• We should validate the functionality both via PYTHONPATH, sdist and wheel.
• Integration tests should live in pytest
• We should reduce the reliance on mocks to the absolute minimum — for example avoid mocking or at least use autospec in these tests.
• End reliance on implementation details such as is happening in this test.

Following the discussion in #99, we have agreed that we should use venv to create virtual environments on Python 3.

pre-commit at the moment tries to piggyback on the local environments, see https://github.com/FFY00/python-build/blob/master/.pre-commit-config.yaml can we instead use the better supported/easier to upgrade, more declarative method? As in https://github.com/pypa/virtualenv/blob/master/.pre-commit-config.yaml#L2

sphinx-apidoc needs to run on the module to generate the API reference. RTD does not support this.

I tried autoapi.extension but it does not correctly annotate __init__ methods.

We will probably have to move the apidoc building step from the makefile to conf.py/custom sphinx extension, but I am not happy about this.

Should we go ahead and move the project over to the PyPA namespace now, even though this milestone has not been hit yet?

I think there's already broad agreement that that will be the eventual home for it, and it's probably best to minimize the number of links to the "old location" (particularly since the "old location" is in @FFY00's personal namespace, which will presumably eventually become his own personal fork, and can't just be a simple redirect).

I think that rather than waiting to complete everything for the milestone, we can do the migration today and call that milestone "Ready for PyPA recommendation" (i.e. the point at which we can migrate packaging.python.org to using python-build).

We should add support to pass config_settings to the PEP517 hooks.

I propose the following:

parser.add_argument('--config', '-C', action='append')

Allowing users to pass arguments as follows:

... -Csomething=value
... -C something=value
... -C 'something with spaces=another value'

This is a pretty standard way to pass extra arguments to build systems and I think it would fit here nicely.

cc @gaborbernat

I want to propose the adoption of python-build for Arch Linux packaging and to avoid breaking things due the default behavior (build in isolation) change in the new version, I propose tagging a 0.0.3.2 release which would be just 0.0.3.1 with a patch to enable the use of the --no-isolation/-n flag.

This way we can write python -m build --no-isolation in our build instructions and not have to change it when the default behavior changes.

cc @pganssle @gaborbernat

It's not true we work with any version of those dependencies.

See https://docs.readthedocs.io/en/stable/guides/autobuild-docs-for-pull-requests.html

This is the same issue as in pep517: pypa/pyproject-hooks#84

If PIP_REQUIRE_VIRTUALENV is set (to a non-empty value) when running python -m build , pip errors with its "ERROR: Could not find an activated virtualenv (required)." message:

$ python -m build
Looking in links: /var/folders/kq/02p9h16n7zv_z7bhzmg6y_pm0000gn/T/tmpo1xlgb08
Processing /private/var/folders/kq/02p9h16n7zv_z7bhzmg6y_pm0000gn/T/tmpo1xlgb08/setuptools-47.1.0-py3-none-any.whl
Processing /private/var/folders/kq/02p9h16n7zv_z7bhzmg6y_pm0000gn/T/tmpo1xlgb08/pip-20.1.1-py2.py3-none-any.whl
Installing collected packages: setuptools, pip
Successfully installed pip setuptools
ERROR: Could not find an activated virtualenv (required).
Traceback (most recent call last):
  File "/Users/chainz/.pyenv/versions/3.8.5/lib/python3.8/runpy.py", line 194, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/Users/chainz/.pyenv/versions/3.8.5/lib/python3.8/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/Users/chainz/.pyenv/versions/3.8.5/lib/python3.8/site-packages/build/__main__.py", line 176, in <module>
    main(sys.argv[1:], 'python -m build')
  File "/Users/chainz/.pyenv/versions/3.8.5/lib/python3.8/site-packages/build/__main__.py", line 168, in main
    build(args.srcdir, args.outdir, distributions, config_settings, not args.no_isolation, args.skip_dependencies)
  File "/Users/chainz/.pyenv/versions/3.8.5/lib/python3.8/site-packages/build/__main__.py", line 80, in build
    _build_in_isolated_env(builder, outdir, distributions)
  File "/Users/chainz/.pyenv/versions/3.8.5/lib/python3.8/site-packages/build/__main__.py", line 45, in _build_in_isolated_env
    env.install(builder.build_dependencies)
  File "/Users/chainz/.pyenv/versions/3.8.5/lib/python3.8/site-packages/build/env.py", line 176, in install
    subprocess.check_call(cmd)
  File "/Users/chainz/.pyenv/versions/3.8.5/lib/python3.8/subprocess.py", line 364, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/Users/chainz/.pyenv/versions/3.8.5/bin/python', '-m', 'pip', 'install', '--prefix', '/var/folders/kq/02p9h16n7zv_z7bhzmg6y_pm0000gn/T/build-env-9j1lejv3', '-r', '/var/folders/kq/02p9h16n7zv_z7bhzmg6y_pm0000gn/T/build-reqs-cc8vednw.txt']' returned non-zero exit status 3.

The solution is to unset the environment variable for the subprocess.

• isolated builds should happen in python environments without any packages
• we should validate functionality both via PYTHONPATH, sdist, wheel
• integration tests need to live within pytest

It's because of https://foss.heptapod.net/pypy/pypy/-/issues/3321

https://github.com/FFY00/python-build/blob/2b18f118cd3021f61613dc3381230ffaa32fad16/src/build/env.py#L160

It's more explicit that way, and, yes, I know this is a nit-pick. 😅

We should either add tests to validate distutils backend works, or drop it and move to setup.cfg.

AFAIK sphinx-autodoc-typehints is being used correctly, not sure why it isn't showing.

@pradyunsg any ideas?

My vote is for not. I'd only separate in logical blocks, mostly check sets.

pypy does not handles/honor/cares about PYTHONHOME, see https://foss.heptapod.net/pypy/pypy/-/blob/branch/default/pypy/interpreter/app_main.py#L38, hence the issues here; prefixes remain under original executable path, which then pulls in the site-packages via https://foss.heptapod.net/pypy/pypy/-/blob/branch/default/lib-python/2.7/site.py#L295-297 and https://foss.heptapod.net/pypy/pypy/-/blob/branch/default/lib-python/2.7/distutils/sysconfig_pypy.py#L38-56 respectively

minimal reproducible:

env PYTHONHOME=this-is-missing pypy -E -m site
sys.path = [
    '/Users/bgabor8/git/github/python-build',
    '/Users/bgabor8/.pyenv/versions/pypy2.7-7.3.0/lib_pypy/__extensions__',
    '/Users/bgabor8/.pyenv/versions/pypy2.7-7.3.0/lib_pypy',
    '/Users/bgabor8/.pyenv/versions/pypy2.7-7.3.0/lib-python/2.7',
    '/Users/bgabor8/.pyenv/versions/pypy2.7-7.3.0/lib-python/2.7/lib-tk',
    '/Users/bgabor8/.pyenv/versions/pypy2.7-7.3.0/lib-python/2.7/plat-darwin',
    '/Users/bgabor8/.pyenv/versions/pypy2.7-7.3.0/lib-python/2.7/plat-mac',
    '/Users/bgabor8/.pyenv/versions/pypy2.7-7.3.0/lib-python/2.7/plat-mac/lib-scriptpackages',
    '/Users/bgabor8/.pyenv/versions/pypy2.7-7.3.0/site-packages',
]
USER_BASE: '/Users/bgabor8/.local' (exists)
USER_SITE: '/Users/bgabor8/.local/lib/pypy2.7/site-packages' (doesn't exist)
ENABLE_USER_SITE: True

vs

env PYTHONHOME=this-is-missing python2.7 -m site
ImportError: No module named site

And it crashes when it doesn’t. This is particularly problematic since the default output directory ($PWD/dist) is usually absent in a newly checked out repository.

This works:

$ python -m build -s -o .

But this fails if ./dist does not exist, with a cryptic message:

$ python -m build -s
Traceback (most recent call last):
  File "lib\subprocess.py", line 1307, in _execute_child
    hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
NotADirectoryError: [WinError 267] The directory name is invalid

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "build\__init__.py", line 143, in build
    raise BuildBackendException('Backend operation failed: {}'.format(e))
build.BuildBackendException: Backend operation failed: [WinError 267] The directory name is invalid

ERROR Backend operation failed: [WinError 267] The directory name is invalid

I've been playing a bit with mutmut, and while it's a bit noisy, it did find this meaningful mutation here:

-     if not config_settings:
+     if config_settings:
        config_settings = {}

I can confirm that this is also not tested in the integration tests.

A less important mutant is that apparently also the default value for skip_dependencies is never tested in _build_in_current_env (which might be an argument for just not giving it a default value).

As discussed, the integration tests to make sure that common packages build successfully (https://github.com/FFY00/python-build/blob/master/.github/workflows/build.yml) should be moved to pytest. This tests should be disabled by default and enabled by passing a CLI argument. Nox/tox should run the integration tests by default(?) and allow us to opt out.

Hi! I saw your note about potentially moving this project to the PyPA.

I don't see a code of conduct in your top-level directory; I suggest you do something like what pip did and add a line to your README saying that interactions with/within the project are subject to the PyPA Code of Conduct. Or prep that change as a pull request, approve it, and then be ready to merge it if/when the project moves into PyPA.

Thanks!

Hi. I'm coming here from pypa/pyproject-hooks#91 as it is noted on the checklist that

Add a deprecation warning when pep517.check is used

Apologies in advance is this is covered in an Issue already and I've failed to find it, but as it isn't mentioned in PR #83, are there plans to also make an equivalent of pep517.check available in the build CLI API?

Though perhaps there isn't an explicit need for the check API (?) given that python-build (and pep517.build) seems to perform the equivalent of pep517.check during its run.

Ubuntu, macOs, Windows.

The Hippocratic License is a permissive license, just like MIT, but enforces the licensee to adhere to human rights principles and laws. This might seem a bit silly but with open software being more widely used, I want to make sure my software takes no part in helping out organizations that violate human rights, such as ICE.

https://firstdonoharm.dev
https://ethicalsource.dev

@felixonmars @gaborbernat @pganssle do you guys agree to relicense your contributions under the Hippocratic License 2.1?

I have the following pyproject.toml:

[build-system]
requires = ["wheel", "setuptools>=42", "setuptools_scm[toml]>=3.4"]

Build fails with:

Looking in links: /tmp/tmpu9cyr1oc
Processing /tmp/tmpu9cyr1oc/setuptools-47.1.0-py3-none-any.whl
Processing /tmp/tmpu9cyr1oc/pip-20.1.1-py2.py3-none-any.whl
Installing collected packages: setuptools, pip
Successfully installed pip setuptools
ERROR: Double requirement given: setuptools>=42 (from -r /tmp/build-reqs-akrau6fv.txt (line 2)) (already in setuptools>=40.8.0 (from -r /tmp/build-reqs-akrau6fv.txt (line 1)), name='setuptools')
WARNING: You are using pip version 20.1.1; however, version 20.2.3 is available.
You should consider upgrading via the '/opt/hostedtoolcache/Python/3.8.5/x64/bin/python -m pip install --upgrade pip' command.
Traceback (most recent call last):
  File "/opt/hostedtoolcache/Python/3.8.5/x64/lib/python3.8/runpy.py", line 194, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/opt/hostedtoolcache/Python/3.8.5/x64/lib/python3.8/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/opt/hostedtoolcache/Python/3.8.5/x64/lib/python3.8/site-packages/build/__main__.py", line 176, in <module>
    main(sys.argv[1:], 'python -m build')
  File "/opt/hostedtoolcache/Python/3.8.5/x64/lib/python3.8/site-packages/build/__main__.py", line 168, in main
    build(args.srcdir, args.outdir, distributions, config_settings, not args.no_isolation, args.skip_dependencies)
  File "/opt/hostedtoolcache/Python/3.8.5/x64/lib/python3.8/site-packages/build/__main__.py", line 80, in build
    _build_in_isolated_env(builder, outdir, distributions)
  File "/opt/hostedtoolcache/Python/3.8.5/x64/lib/python3.8/site-packages/build/__main__.py", line 45, in _build_in_isolated_env
    env.install(builder.build_dependencies)
  File "/opt/hostedtoolcache/Python/3.8.5/x64/lib/python3.8/site-packages/build/env.py", line 176, in install
    subprocess.check_call(cmd)
  File "/opt/hostedtoolcache/Python/3.8.5/x64/lib/python3.8/subprocess.py", line 364, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/opt/hostedtoolcache/Python/3.8.5/x64/bin/python', '-m', 'pip', 'install', '--prefix', '/tmp/build-env-6o04yjl_', '-r', '/tmp/build-reqs-akrau6fv.txt']' returned non-zero exit status 1.

However, there is a missing line - and adding it fixed the problem:

build-backend = "setuptools.build_meta"

a) Is it possible to improve the error message and b) should this error be happening anyway? It seems to be trying to recursively produce all the requirements manually and put then into a requirements.txt-like file, which then collide?

Something like https://virtualenv.pypa.io/en/latest/changelog.html#v20-0-24-2020-06-22

I propose the usage of towncrier for this. @FFY00?

We where using the previous pypi project build. Did the previous owner transfer or was it abandoned? As our builds are broken today and trying to work out the best way around this.

At the moment in our codebase we special handle it, but we shouldn't. See https://foss.heptapod.net/pypy/pypy/-/issues/3323 for the root issue. IMHO we can keep just always the with pip branch, and disable the isolation test until it's fixed together with https://foss.heptapod.net/pypy/pypy/-/issues/3321

Would you be ok with using the black formatter on the codebase?

When you run from inside a venv (in my case, a venv inside conda), then python -m build uninstalls setuptools after running python -m build.

And then, on a second run, it immediately breaks, even with setuptools listed in the requires clause (assuming it is needed for ensurepip, perhaps?)

python3 -m venv venv
. venv/bin/activate.fish
python -m pip install build
python -m build
# setuptools is now gone
python -m build
ERROR Backend 'setuptools.build_meta' is not available

Probably closely related to #97 . I am in the same anaconda python3.7 env described in #108, only now with a "setuptools>=42" requirement.

PEP 517 mandates “all hooks are run with working directory set to the root of the source tree”. This is important for in-tree hooks since the cwd is relied on to find the PEP 517 modules.

This fails:

$ python -m build ./example-project -s -o .
ERROR Backend 'pep517' is not available

But this works:

$ cd example-project
$ python -m build -s -o .
$ ls *.tar.gz
my_package-2.tar.gz

Can we turn off the codecov comment bot? I find it spammy and annoying, and I can't figure out a way to prevent it from sending me e-mails every time someone pushes a commit. The status hook should be enough.

Pybind11's build process (in current master) does perform a few tricks. But it works perfectly with pip wheel and pep517.build. And python -m build, but only if using Python 3.6 or 3.8. In Python 3.7, it fails with one of two errors:

Building with just the output sdist in the directory (either python -m build or python -m build -w after building the sdist):
There is an error (below) and the dist directory is gone after the command.

removing build/bdist.macosx-10.7-x86_64/wheel
Traceback (most recent call last):
  File "/usr/local/Caskroom/miniconda/base/envs/pybind11test/lib/python3.7/site-packages/pep517/_in_process.py", line 280, in <module>
    main()
  File "/usr/local/Caskroom/miniconda/base/envs/pybind11test/lib/python3.7/site-packages/pep517/_in_process.py", line 263, in main
    json_out['return_val'] = hook(**hook_input['kwargs'])
  File "/usr/local/Caskroom/miniconda/base/envs/pybind11test/lib/python3.7/site-packages/pep517/_in_process.py", line 205, in build_wheel
    metadata_directory)
  File "/var/folders/_8/xtbws09n017fbzdx9dmgnyyr0000gn/T/build-env-55xcdz6_/lib/python3.7/site-packages/setuptools/build_meta.py", line 176, in build_wheel
    shutil.copytree('dist', wheel_directory)
  File "/usr/local/Caskroom/miniconda/base/envs/pybind11test/lib/python3.7/shutil.py", line 315, in copytree
    names = os.listdir(src)
FileNotFoundError: [Errno 2] No such file or directory: 'dist'
Traceback (most recent call last):
  File "/usr/local/Caskroom/miniconda/base/envs/pybind11test/lib/python3.7/subprocess.py", line 347, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/usr/local/Caskroom/miniconda/base/envs/pybind11test/bin/python', '/usr/local/Caskroom/miniconda/base/envs/pybind11test/lib/python3.7/site-packages/pep517/_in_process.py', 'build_wheel', '/var/folders/_8/xtbws09n017fbzdx9dmgnyyr0000gn/T/tmpgicpuv66']' returned non-zero exit status 1.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/Caskroom/miniconda/base/envs/pybind11test/lib/python3.7/site-packages/build/__init__.py", line 215, in build
    raise BuildBackendException('Backend operation failed: {}'.format(e))
build.BuildBackendException: Backend operation failed: Command '['/usr/local/Caskroom/miniconda/base/envs/pybind11test/bin/python', '/usr/local/Caskroom/miniconda/base/envs/pybind11test/lib/python3.7/site-packages/pep517/_in_process.py', 'build_wheel', '/var/folders/_8/xtbws09n017fbzdx9dmgnyyr0000gn/T/tmpgicpuv66']' returned non-zero exit status 1.

ERROR Backend operation failed: Command '['/usr/local/Caskroom/miniconda/base/envs/pybind11test/bin/python', '/usr/local/Caskroom/miniconda/base/envs/pybind11test/lib/python3.7/site-packages/pep517/_in_process.py', 'build_wheel', '/var/folders/_8/xtbws09n017fbzdx9dmgnyyr0000gn/T/tmpgicpuv66']' returned non-zero exit status 1.

Making an SDist with another SDist present in the directory (pybind11 can make an alternate SDist):
There is an error (below). The directory remains intact.

Creating tar archive
removing 'pybind11-2.6.0.dev1' (and everything under it)
Traceback (most recent call last):
  File "/usr/local/Caskroom/miniconda/base/envs/pybind11test/lib/python3.7/site-packages/pep517/_in_process.py", line 280, in <module>
    main()
  File "/usr/local/Caskroom/miniconda/base/envs/pybind11test/lib/python3.7/site-packages/pep517/_in_process.py", line 263, in main
    json_out['return_val'] = hook(**hook_input['kwargs'])
  File "/usr/local/Caskroom/miniconda/base/envs/pybind11test/lib/python3.7/site-packages/pep517/_in_process.py", line 236, in build_sdist
    return backend.build_sdist(sdist_directory, config_settings)
  File "/var/folders/_8/xtbws09n017fbzdx9dmgnyyr0000gn/T/build-env-w0z4p4jx/lib/python3.7/site-packages/setuptools/build_meta.py", line 188, in build_sdist
    return _file_with_extension(sdist_directory, '.tar.gz')
  File "/var/folders/_8/xtbws09n017fbzdx9dmgnyyr0000gn/T/build-env-w0z4p4jx/lib/python3.7/site-packages/setuptools/build_meta.py", line 94, in _file_with_extension
    file, = matching
ValueError: too many values to unpack (expected 1)
Traceback (most recent call last):
  File "/usr/local/Caskroom/miniconda/base/envs/pybind11test/lib/python3.7/subprocess.py", line 347, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/usr/local/Caskroom/miniconda/base/envs/pybind11test/bin/python', '/usr/local/Caskroom/miniconda/base/envs/pybind11test/lib/python3.7/site-packages/pep517/_in_process.py', 'build_sdist', '/var/folders/_8/xtbws09n017fbzdx9dmgnyyr0000gn/T/tmpbgghz54l']' returned non-zero exit status 1.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/Caskroom/miniconda/base/envs/pybind11test/lib/python3.7/site-packages/build/__init__.py", line 215, in build
    raise BuildBackendException('Backend operation failed: {}'.format(e))
build.BuildBackendException: Backend operation failed: Command '['/usr/local/Caskroom/miniconda/base/envs/pybind11test/bin/python', '/usr/local/Caskroom/miniconda/base/envs/pybind11test/lib/python3.7/site-packages/pep517/_in_process.py', 'build_sdist', '/var/folders/_8/xtbws09n017fbzdx9dmgnyyr0000gn/T/tmpbgghz54l']' returned non-zero exit status 1.

ERROR Backend operation failed: Command '['/usr/local/Caskroom/miniconda/base/envs/pybind11test/bin/python', '/usr/local/Caskroom/miniconda/base/envs/pybind11test/lib/python3.7/site-packages/pep517/_in_process.py', 'build_sdist', '/var/folders/_8/xtbws09n017fbzdx9dmgnyyr0000gn/T/tmpbgghz54l']' returned non-zero exit status 1.

Again, in both cases, this only happens with 3.7:

# macOS 10.15, Miniconda from brew
git clone https://github.com/pybind/pybind11
cd pybind11
conda create -n pybind11test python~=3.7
conda activate pybind11test
pip install build
python -m build -s
python -m build -w # BROKEN
# SDist directory gone

python -m build -s
PYBIND11_GLOBAL_SDIST=1 python -m build -s # Second line breaks, regardless of which one you do first

change the 3.7 to 3.8 or 3.6, and both cases above work flawlessly.

It seems to only happen in conda - testing in CI works on linux and macOS when set to 3.7 and given the same dependencies. But it was reported and I was able to reproduce.

Package            Version
------------------ -------------------
build              0.0.4
certifi            2020.6.20
importlib-metadata 2.0.0
packaging          20.4
pep517             0.8.2
pip                20.2.2
pyparsing          2.4.7
setuptools         49.6.0.post20200925
six                1.15.0
toml               0.10.1
wheel              0.35.1
zipp               3.2.0

I just wanted to open this to discuss the release process a bit.

I really want for all releases to be PGP signed, I have a strong position on this. This means when releasing we would create a signed tag git tag -s 1.0.0.

All keys allowed to release should be listed here.

Following the current model the release title/description should be:

python-build 1.0.0

- Some new change
- Some other change
- Some bug that was fixed
...

This relates to #39 which asks for changelogs to be exported.

Does anyone have thoughts? Is there anything you don't agree, or something you would like to change?

If there are no objections we can go ahead and add a CONTRIBUTING.md file describing the process.
Maybe the release should be automated in a release script, what do you think?

cc @gaborbernat @pganssle

This is because ensurepip pulls in automatically setuptools, so that's auto-provisioned.

If pyproject.toml includes a build dependency that isn't present in the system site-packages, this should be reported and the build aborted.

To demonstrate the issue, create a simple project that depends only on setuptools and wheel, but add numpy to build-system.requires. The build will succeed even though the declared dependencies are not present.