| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
| | |
| | |
| | |
| | | |
Since it is deprecated and relevant details have already been covered in
a separate Dependencies Management page.
|
| | |
| | |
| | |
| | |
| | | |
Explains why quoting around `timmins.display` is required. Might be
helpful for beginners.
|
| | |
| | |
| | |
| | |
| | |
| | | |
Indentation was 8 spaces. Should be 4 spaces for consistency with other
`setup.cfg` snippets.
Also fixed up tab/spaces glitches in other places.
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
Had incorrectly used `timmins_plugin_fancy` instead of
`timmins-plugin-fancy` in several places.
|
|/ /
| |
| |
| |
| | |
Had used `=` for separating key and value pair in dictionary, should
have `:` instead.
|
|\ \ |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- Old example was on loading entry points corresponding to console
scripts.
- Everything in that example has probably been included in the newer
example.
|
| | |
| | |
| | |
| | |
| | |
| | | |
- Defining multiple EPs under the same group
- Loading an EP by its name
- Loading all EPs in a given group
|
| | | |
|
| | |
| | |
| | |
| | | |
In the Advertising Behaviour section.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- Indicated that for Python versions lower than 3.8, the backport
should be used.
- Indicated that the only change that needs to be made while using the
backport, is to replace `importlib.metadata` with
`importlib_metadata`.
|
| | |
| | |
| | |
| | | |
Snippet borrowed from Python Packaging user guide
|
| | | |
|
| | |
| | |
| | |
| | | |
Fixes warning emitted during `tox -e docs`
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
`PySimpleGUI` must be added to package dependencies in order to run the example in the GUI scripts section.
Co-authored-by: Anderson Bravalheri <andersonbravalheri+github@gmail.com>
|
| | |
| | |
| | | |
Co-authored-by: Anderson Bravalheri <andersonbravalheri+github@gmail.com>
|
| | |
| | |
| | |
| | |
| | |
| | | |
Changed the wording of the console scripts example, so that it is more
clear why `__main__.py` is required and why console scripts are a better
alternative.
|
| | |
| | |
| | |
| | |
| | |
| | | |
Added two lines to make this clear to users. Also added that any parsing
of user input can take place within the body of the function using
regular command-line parsing utilities.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Removed a line stating that installers like Pip create wrapper scripts
around the function, and replaced it with a longer note at the end of
the GUI scripts section. This note includes a sample wrapper script
taken from the Python Packaging user guide. I think this longer note
along with an actual example of how the wrapper script might look like
will make it more clear to the user how console/GUI scripts work behind
the scenes.
|
| | |
| | |
| | |
| | |
| | |
| | | |
This note has been taken from the Python Packaging user guide. I think
it will be of interest to users who want to understand what is the
difference between `console_scripts` and `gui_scripts`.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- Made separate section for `gui_scripts`
- Added an example `hello_world()` function that can be invoked using
a GUI script entry point
- Added `setup.cfg`, `setup.py` and `pyproject.toml` configuration
snippets
- Added that running `hello-world` in the terminal will open up a GUI
window.
|
| | |
| | |
| | |
| | |
| | |
| | | |
- Added output of the command `python -m timmins`.
- Added input and output when a console script is set up, i.e. when
`hello-world` is run on the terminal.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- I think there is no need to include name, version, `packages`, etc.
They haven't been included in the equivalent `setup.cfg` snippet as
well as in other snippets in the documentation.
- Fixed up indentation by changing tabs to 4 spaces.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- Using `src` layout for consistency with other examples in the
documentation.
- Using a tree diagram.
- Showing a `setup.py` file in the diagram with a comment indicating
that `setup.cfg` or `pyproject.toml` can also be used, again for
consistency with other examples in the documentation.
- Root directory is kept as `project_root_directory` to indicate that
any name can be used.
|
| | |
| | |
| | | |
Co-authored-by: cdfarrow <cdfarrow@users.noreply.github.com>
|
| | | |
|
| | | |
|
|/ / |
|
| |
| |
| |
| |
| |
| | |
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.
|