-
Notifications
You must be signed in to change notification settings - Fork 7
Packaging a Python project
Louis Maddox edited this page Feb 8, 2021
·
41 revisions
-
git init -
.gitignore, see examples:-
pyx-sys and mvdef
- packaged projects with vim swap files and Python build/dist artifacts (
build,dist,.eggsetc.)
- packaged projects with vim swap files and Python build/dist artifacts (
-
dx
- a packaged project as above, also with
store/andtmp/data directories
- a packaged project as above, also with
- emoji-liif with Jupyter notebooks
-
pyx-sys and mvdef
-
README.md- title e.g.
# myproject(add a brief description, copy this to the GitHub repo description) -
## Usage(brief note on what usage will look like if you've not written it yet) -
## Requirementslist- Python 3and if there are many packages, put them on one line usually- These should be the proper human-readable names (the pip names may differ, they go in requirements.txt)
- If there are complex conda environment requirements or different options, write a little backticked block
to reproduce it (as here for
emoji-liif)
- title e.g.
-
LICENSE
- If you haven't pushed to GitHub yet, copy a LICENSE (the text will be detected)
- E.g. from dx (click 'Raw' to get plain text)
- If you haven't pushed to GitHub yet, copy a LICENSE (the text will be detected)
-
pyproject.toml
- Handles the requirements for building binaries/wheels to ship (not required for package users),
namely
setuptools,wheel,setuptools_scmfor auto-versioning - Copy the one for mvdef
- Versioning is incremented by git tags (see the tags for mvdef for examples). These allow you to do 'releases' (again see mvdef)
- Handles the requirements for building binaries/wheels to ship (not required for package users),
namely
-
echo > requirements.txt(if you haven't written any code yet, otherwise list requirements for pip) -
setup.py
- Handles the metadata for pip installation
- Copy an example like dx
- Change the classifiers for 'intended audience', license, and so on, to match your project
-
find_packageswill auto-detect the package insidesrc - If you want command-line entrypoints these can be added (e.g.
mvdef has 4 such
console_scripts) - The
version_schemeinterprets thegit tagto auto-version upon each new tag- I use helper functions
retag_republish_major/minor/micro to automate the simultaneous git tag and PyPi republish steps, see Rebuild Python package for PyPi and republish for code/further details
- I use helper functions
Paths in the following sections are under src/pkgname (replacing 'pkgname' with your package)
-
shareindicates/src/pkgname/share
- Create modules for each section (e.g.
share,dataset,model) as well as a top-level__init__.pyand any computation for things to be exported into the main namespace there inutils.py(but do not crowd this directory with anything else!)
-
Keep data separate from computation on that data
-
srccontains both but not in the same subdirectories
-
-
Keep fixed data files used for computation in
share/data- This will be included in the distributed package via
setup.pyby settinginclude_package_data=Trueinsetuptools.setup()
- This will be included in the distributed package via
-
Keep artifacts [outputs computed from running your package code] in
store/- This will be excluded from the distributed package via
.gitignoreby the line**/store/*
- This will be excluded from the distributed package via
-
Don't put data at the top-level (above
src) outside the package, your code won't be able to interact with it properly (by exposing directory paths from__init__.pyfiles)-
as done for
dxinshare/data/__init__.pyfrom . import __path__ as _dir_nspath from pathlib import Path as _Path __all__ = ["dir_path"] dir_path = _Path(list(_dir_nspath)[0])
which is then provided to the
share.scraper.parse_topicsmodule:from ..data import dir_path as data_dir
-