| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
For the `exclude_package_data` example added recently, there were single
backticks around `.gitignore`, `.gitattributes` etc. which leads to the
docs failing to build locally.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Just to make it clear that we can use either one of `package_data` or
`include_package_data` and not just the former.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Added `include_package_data`, `package_data` and
`exclude_package_data` sections to make clear the three options
provided by Setuptools to manage data files.
- Added a separate section illustrating the use of a `data`
subdirectory, after these three sections.
- Placed the summary of the three options under a Summary section.
- Changed the levels of the last two sections to match the level of
the five sections added.
- Small changes. Changed the wording where appropriate to suit the new
flow. Changed a paragraph on path separators in glob patterns to a
Note.
|
| |
|
|
|
|
|
| |
This footnote describes what Setuptools considers as a data file. This
note is important and may be missed by the reader if it is kept as a
footnote, hence I have copied its contents up ahead in the document,
just after the `include_package_data` example.
|
| |
|
|
| |
For consistency.
|
| |
|
|
|
| |
I believe this footnote is outdated and not required in lieu of the
added notes describing compatibility with different Python versions
|
| |
|
|
|
|
|
|
|
|
|
| |
- Added example package tree
- Added snippet on how typically the `__file__` attribute would be
used
- Added snippet showing usage of `importlib.resources` with the
`files()` API
- Added notes on compatibility of this code with different Python
versions along with references
- Added snippet to show usage of `importlib_resources` backport
|
| |
|
|
|
|
|
|
|
| |
In the end of the document, in the summary section, there is a line
stating that the files matched by `package_data` do not require a
corresponding `MANIFEST.in` or a revision control system plugin. Have
included this note higher up in the document because I felt it may be of
interest to users and they might miss this line so far down the
document.
|
| |
|
|
|
|
| |
Made them consistent with the snippets given on the Package Discovery
page. The changes made here are similar to the changes made to the
previous example.
|
| |
|
|
| |
Tried to make why this option is useful more clear.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Made them consistent with the snippets given on the Package Discovery
page.
- Instead of enumerating a list of all the packages in `packages`,
using `find_packages` or `find:` instead. The `find_packages` call in
`setup.py` contains a `where` argument. In `setup.cfg`, included the
section `options.packages.find` with a `where` option.
- Instead of supplying the same `package_dir` for each package, using
an empty string to indicate a `package_dir` for all packages.
- In `pyproject.toml`, using the `where` option instead of
`package-dir`.
- Textual changes.
|
| |
|
|
|
|
| |
Modified code snippets for `package_data` example with `data`
subdirectory to treat the `data` subdirectory as a namespace package.
Also modified a paragraph below these snippets.
|
| |
|
|
|
|
|
|
| |
Removed the statement within the parentheses, since the example which
follows does not illustrate this specific example (of having
documentation files that you may not want to include in the
installation). Besides the `exclude_package_data` option covers this
exact use case in a later example.
|
| |
|
|
|
|
|
|
|
|
| |
Have tried to make the working of the `include_package_data` option as
clear as possible.
- Added a package tree
- Tried to clearly state that the data files must be either included in
`MANIFEST.in`, or tracked by a VCS, in order for them to be included
in the installation of the package, when `include_package_data=True`.
- Added a `MANIFEST.in` snippet to make things more clear.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- All code snippets were given for `setup.py`. Have added
corresponding snippets for `setup.cfg` and `pyproject.toml`.
- To avoid incentivizing multiple top-level packages, have modified
all the package trees and code snippets to include only a single
package `mypkg`. Have added a separate example to illustrate the
functionality of using the empty string `""` / the asterisk `*` for
capturing data files from multiple packages. Have also modified the
`setup.py` code snippets and removed the `find_packages("src")`
since there is only a single package in each case (except one); have
opted to explicitly name the package instead.
- Have added a package tree example for the first `package_data`
snippet. Have also added a package tree / code snippet example to
show how `package_data` patterns should include subdirectories,
separating it from the example showing the empty string `""` /
asterisk `*` functionality.
- Tried to have consistent naming for all directories and data files
used in the package trees and code snippets. All directories have
been named `mypkg` and data files have been named `data1.txt`,
`data2.rst` etc.
- Have reformatted package tree examples. Reformatting has been done
by replacing the only-indentation based directory structure diagram
with a line-based tree layout; I think this looks neater.
- Have added `.. note::` blocks for paragraphs that would be more
appropriately phased as a Note. Other minor changes to text content
have been made.
|
| |
|
| |
Co-authored-by: Steven Silvester <steven.silvester@ieee.org>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
