build VS setuptools

If it's pure Python, the only packaging file you need is `pyproject.toml`. You can fill that file with packaging metadata per PEP 518 and PEP 621, including using modern build tooling like flit[1] for the build backend and build[2] for the frontend.

With that, you entire package build (for all distribution types) should be reducible to `python -m build`. Here's an example of a full project doing everything with just `pyproject.toml`[3] (FD: my project).

[1]: https://github.com/pypa/flit

[2]: https://github.com/pypa/build

[3]: https://github.com/pypa/pip-audit

RE the dislike of a "third-party tool", what do you mean by this? All the major tools for packaging in Python are under the PyPA, e.g. - twine - build - hatch

building wheels/sdists to upload or install: build

python3 setup.py sdist bdist_wheel - no need for an sdist when building wheels, also I'd recommend using pypa/build instead.

The first step is to turn the internal package into a wheel (a *.whl file). We can use the build tool for this purpose. After installing build with pip we can run it as follows:

Shouldn't https://github.com/pypa/build help? I don't think it has enough features yet but I was under the impression that was the distro solution.

To be fair, that seems to have been a 2 year warning:

https://github.com/pypa/setuptools/commit/3544de73b3662a27fa...

There was/is some discussion in setuptools about how to normalize the tarball (https://github.com/pypa/setuptools/issues/2133#issuecomment-...) coudl something similar be applied to Building Python itself ?

❯ yay -Sy python-setuptools python-jaraco.text ❯ pip show setuptools Name: setuptools Version: 67.7.0 Summary: Easily download, build, install, upgrade, and uninstall Python packages Home-page: https://github.com/pypa/setuptools Author: Python Packaging Authority Author-email: [email protected] License: Location: /usr/lib/python3.11/site-packages Requires: jaraco.text, more-itertools, ordered-set, packaging, platformdirs, tomli, validate-pyproject Required-by: Cerberus, fs, httpie, input-remapper, pecan, pycountry, python-lsp-server, reuse, setuptools-scm, zc.lockfile

For example, when it comes to Python, one option is to use the same packaging system that a huge number of open-source libraries and tools are published with. You can use setuptools or Hatch to build a "packaged" version of your code, and publish it to either the public PyPi repository or an internal one that you set up. Then your users can use pip to install your package, automatically fetch its dependencies, and keep it up to date, just like any other Python module.

You could maybe make it a click Application, and use setuptools.

Not sure how advisable it is to depend on setup.py given the setuptools team has very clearly stated that they are not interested in supporting any cli commands anymore including setup.py install. Relavant PR

This structure is essentially a variant of what's known as the src package layout - with the src directory renamed as layer. For this project I'm using setuptools as the packaging tool, and I'm configuring the package declaratively using a setup.cfg file.

Yeah, that's definitely a problem. There's a lot of room for improvement there, and the upcoming v2.0.0 release will improve things a bit by getting rid of the pkg_resources dependency which takes a lot of time to import.