pypa / build Goto Github PK
View Code? Open in Web Editor NEWA simple, correct Python build frontend
Home Page: https://build.pypa.io
License: MIT License
A simple, correct Python build frontend
Home Page: https://build.pypa.io
License: MIT License
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
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?
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
We should either add tests to validate distutils backend works, or drop it and move to setup.cfg
.
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
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.
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 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
).
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.
Would you be ok with using the black formatter on the codebase?
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!
Such as .tox
, which usually takes a long time to copy on Windows.
Docs for ignore
callable kwarg here: https://docs.python.org/3/library/shutil.html#shutil.copytree
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.
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
).
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?
This is because ensurepip pulls in automatically setuptools, so that's auto-provisioned.
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?
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.
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.
build 0.0.4 uses ensurepip to ensure pip before installing build dependencies:
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:
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.
(To reproduce, just run sdist creation twice, once with PYBIND11_GLOBAL_SDIST
set.)
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
(zipp is not present in 3.8 or 3.6 env, but removing it doesn't affect anything)
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)?
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.
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
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?
My vote is for not. I'd only separate in logical blocks, mostly check sets.
It's because of https://foss.heptapod.net/pypy/pypy/-/issues/3321
Following the discussion in #99, we have agreed that we should use venv to create virtual environments on Python 3.
It's not true we work with any version of those dependencies.
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.
Should we run mypy via a tox/nox env, or via a pre-commit hook https://github.com/pre-commit/mirrors-mypy?
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.
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).
$ python-build
...
TypeError: main() missing 1 required positional argument: 'cli_args'
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:
setuptools
and wheel
).PYTHONPATH
, sdist
and wheel
.pytest
autospec
in these tests.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?
Ubuntu, macOs, Windows.
AFAIK sphinx-autodoc-typehints is being used correctly, not sure why it isn't showing.
@pradyunsg any ideas?
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.
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.
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 👍
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?
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.
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
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.
It's more explicit that way, and, yes, I know this is a nit-pick. 😅
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.