| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | | |
| | | | |
| | | | | |
Windows does not change the working directory for a process via `cd .. && <process>` (see e.g. this question: https://stackoverflow.com/q/55641332/8575607 ). This commit replaces the use of `cd .. &&` with arguments provided by `git` and `hg` respectively.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
uniquify paths in PYTHONPATH
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
duplicate entries.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
When running in a complex environment with lots of installed
packages, PYTHONPATH gets way too long. Instead, just make sure
that paths_on_pythonpath doesn't contain duplicates
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
characters.
|
| | | | | | |
|
| | | | | | |
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Support requirement parsing in setuptools.build_meta
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Since pkg_resources is imported elsewhere anyway, we don't get much
value out of porting the requirement parser locally.
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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.
|
|/ / / / / / |
|
|/ / / / /
| | | | |
| | | | | |
Found by lgtm
|
| | | | | |
|
|/ / / /
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Using the absolute path to the directory of the setup script better
mimics the semantics of a direct invocation of python setup.py.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Per Nick Coghlan's suggestion on PR #1652, a try/finally block ensures
that the path is restored even in the event of an error.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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>
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In order to support both the `build_meta` and `build_meta_legacy`
backends, the core functionality is wrapped in a class with methods to
be overridden in build_meta_legacy. The class is an implementation
detail and should remain private.
|
|\ \ \ \
| | | | |
| | | | |
| | | | | |
Bump version: 40.7.2 → 40.7.3
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
urllib.parse.urlparse is clumsy and causes problems as reported in #1663 and #1668. Alternative to #1499 and fixes #1668.
|
|\ \ \ \ \
| |/ / / /
| | | | | |
Ensure port is included in package-index
|
| | | | |
| | | | |
| | | | |
| | | | | |
the URL when auth is present. Fixes #1663.
|
|\ \ \ \ \
| |/ / / / |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
|\ \ \ \ \
| |/ / / / |
|
| |\ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
benoit-pierre/fix_889_and_non-ascii_in_setup.cfg_take_2
improve encoding handling for `setup.cfg`
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
ConfigParser.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
string detection.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
upstream, just incorporate the functionality directly.
|
| | |\ \ \ \
| | | |/ / / |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
| | | | | | |
|
| | |/ / /
| |/| | | |
|
| | | | | |
|
| | | | | |
|