| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
4249da1ecf uses `pathlib.Path.resolve()` instead of `os.path.abspath()`
to canonicalize path names. `resolve()` resolves symlinks, whereas
`abspath()` does not. `resolve()` can also raise a `RuntimeError` if
infinite loops are discovered while resolving the path. There is some
concern that using `resolve()` would not be backwards compatible. This
commit switches back to `abspath()` but still uses `Path.parents` to
avoid the edge case. See PR #3595 for more details.
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Using str.startswith() has an edge case where someone can access files
outside the root directory. For example, consider the case where the
root directory is "/home/user/my-package" but some secrets are stored in
"/home/user/my-package-secrets". Evaluating a check that
"/home/user/my-package-secrets".startswith("/home/user/my-package") will
return True, but the statement's intention is that no file outside of
"/home/user/my-package" can be accessed.
Using pathlib.Path.resolve() and pathlib.Path.parents eliminates this
edge case.
|
| | | |
|
| |/ |
|
| |\ |
|
| | |
| |
| |
| | |
not have a value
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
When walking the ast of a module, look for AnnAssign nodes in addition
to Assign to support assignments with type annotations, for example.
Since we have to read different attributes, split the generators into
a for loop. Existing ast.Assign nodes follow the same processing as
before.
|
| | | |
|
| |/
|
|
|
|
|
| |
PEP 517 does not care if other directories/files are left behind in the
`metadata_directory`, as long as a `.dist_info` directory is produced at
the root. We can leave the `.egg-info` directory behind, so this way
we don't have to run it again when listing files from `build_py`.
|
| | |
|
| |
|
|
|
|
|
|
| |
If the directory follows a src-layout-ish, try harder to
make `package_dir` in the form `{"": "src"}`.
This might be later important for PEP 660 (e.g. when composing pth
files or symlinking the toplevel packages).
|
| |\ |
|
| | | |
|
| |/
|
|
| |
And also avoid using './' paths
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
setup.cfg
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The user might specify dynamic `entry-points` via a `file:`
directive (a similar feature for `setup.cfg` is documented in
[declarative config]).
The changes introduced here add the ability to expand them
when reading the configuration from `pyproject.toml`.
[declarative config]: https://setuptools.pypa.io/en/latest/userguide/declarative_config.html
|
| |
|
|
| |
Co-authored-by: Sviatoslav Sydorenko <wk.cvs.github@sydorenko.org.ua>
|
| | |
|
| | |
|
| | |
|
|
|
We can split the process of interpreting configuration files into 2 steps:
1. The parsing the file contents from strings to value objects
that can be understand by Python (for example a string with a comma
separated list of keywords into an actual Python list of strings).
2. The expansion (or post-processing) of these values according to the
semantics ``setuptools`` assign to them (for example a configuration field
with the ``file:`` directive should be expanded from a list of file paths to
a single string with the contents of those files concatenated)
The idea of this change is to extract the functions responsible for (2.)
into a new module, so they can be reused between different config file
formats.
|
