| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\ \ \ \
| | | | |
| | | | | |
Crash when invalid python_requires indicated in setup.cfg
|
| | | | | |
|
| | |_|/
| |/| | |
|
| | | |
| | | |
| | | |
| | | | |
packaging. Fixes #1858.
|
|\| | | |
|
| | | |
| | | |
| | | |
| | | | |
Do not test pip's master on 3.4, as support for it has been dropped.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Ensure the dictionary values are lists/tuples of strings.
Fix #1459.
|
| |/ / |
|
| | |
| | |
| | |
| | |
| | | |
* ignore distutils' warning (`Unknown distribution option: 'python_requires'`)
* fix test on Windows
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fix the following cases:
* `build_sdist` is called with another sdist already present
in the destination directory
* `build_wheel` is called with the destination directory not
already created
|
| |\ \
| | | |
| | | | |
Fix error with PEP 517 builds when wheel exists (GH #1761)
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
`build_meta.build_wheel` assumes that the only wheel in its output
directory is the one it builds, but prior to this, it also used the
`dist/` folder as its working output directory. This commit uses a
temporary directory instead, preventing an error that was triggered when
previously-generated wheel files were still sitting in `dist/`.
Fixes GH #1671
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
As a mitigation for #1730, this commit limits the number of workers in
the ProcessPoolExecutor to 1 (default is the number of CPUs). On PyPy,
having a higher number of available workers dramatically increases the
number of concurrent processes, leading to some resource exhaustion
issues.
This does not address the root issue, but should improve the situation
until the root issue is addressed.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Currently, this will fail because setuptools.build_meta.build_wheel
assumes that no wheels already exist in the `dist/` directory.
See GH #1671
|
| | |
| | |
| | | |
Checking for new implementation solving issue #1740
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
characters.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This fixes GH #1682 by porting the pkg_resources requirement parsing
logic into setuptools.build_meta, so that all valid requirement
specifiers passed to setup_requires will be added to the
get_requires_for_build_* function outputs.
Fixes GH #1682
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Per GH #1682, with setuptools.build_meta we are not properly handling
the situation where setup_requires is actually a newline-delimited
string rather than a list, which is supported by setup.py interface.
This adds several failing (and some passing) tests for how
setup_requires is handled by setuptools.build_meta.
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
Parametrize the test to check different versions of pip
(including master) are correctly supported.
|
| | | |
|
|/ / |
|
| |
| |
| |
| |
| |
| | |
Many projects can get away with an empty `setup.py` and use *only* the
declarative `setup.cfg`. With the new PEP 517 backend, we can supply a
default empty `setup.py` if one is not provided.
|
| | |
|
| |
| |
| |
| |
| |
| | |
Rather than exposing a top-level module for the legacy backend, we will
move the legacy backend into the `setuptools.build_meta` module and
specify it using the module:object syntax.
|
| |
| |
| |
| |
| |
| |
| | |
This is part of the solution to GH #1642, it is a
backwards-compatibility backend that can be used as a default PEP 517
backend for projects that use setuptools but haven't opted in to
build_meta.
|
| |
| |
| |
| |
| |
| | |
This runs all build_meta tests, plus a test that it is possible to
import from the directory containing `setup.py` when using the
build_meta_legacy backend.
|
| |
| |
| |
| |
| |
| | |
Failing test adapted from PR #1643
Co-authored-by: Tzu-ping Chung <uranusjr@gmail.com>
|
| | |
|
|\ \ |
|
| | | |
|
| | | |
|
|\| | |
|
| |\ \
| | | |
| | | |
| | | |
| | | | |
benoit-pierre/fix_889_and_non-ascii_in_setup.cfg_take_2
improve encoding handling for `setup.cfg`
|
| | |\| |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Support the same mechanism as for Python sources for declaring
the encoding to be used when reading `setup.cfg` (see PEP 263),
and return the results of reading it as Unicode.
Fix #1062 and #1136.
|
| | | | |
|
| | |/
| |/| |
|
| | | |
|
| | | |
|
| |\ \
| | | |
| | | | |
Disallow files for license inputs
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Both the old and new approaches are deeply unsatisfying to me, but
without reworking how these test commands are run, I think this is
about as close as we can get to enforcing that this specific call
raises ValueError.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The ability to handle files was originally added and documented based on
a misunderstanding of what the `license` field should include. The field
should be the name of the license, not the full text.
It is likely that anyone actually using this was outputing malformed
PKG-INFO files, because most license files contain newlines.
See GH issue #1551
|
| |/ / |
|