build VS pipx

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.

Use pipx to install Cog and my aws-sso-config-builder tool in the same environment:

Given how useful pre-commit is across projects I generally recommend installing via pip install --user, making it part of a tooling virtual environment, or using pipx:

I would recommend going with PipX. You toss in a setup.py file, put your project on github, and then anyone on any OS can pipx install your project. It's a glorious thing. The only thing they need is 1) some supported version of Python installed, 2) pipx installed. They can even get updates by calling pipx upgrade.

See https://github.com/pypa/pipx/issues/278

Good overview. There are quite a few on there I was not aware of. That said, I am not sure the organizational schema makes a tone of sense. I would assume most users that come across this would be looking for a package manager for a specific platform and then weighing the options of binary/source/etc., instead of the other way around.

Also, pipx (https://github.com/pypa/pipx) would be a good addition to the list. I'd add it but I'm not sure where it would go. Maybe every section? It's cross platform and handles both binary and source based app distributions.

Pip is pretty simple and useful for me - you have your own environment for every script/program, requirements.txt is simple to understand too... It's kinda good solution for regular users... For more complex projects we have Poetry, PipX, that was inspired by NPM(x), I think...

What benefit would joining your cult bestow upon me that brew does not already?

My brew list is intentionally very short and my faffing about desire is limited.

Generally I use brew to pull in asdf (https://github.com/asdf-vm/asdf) to install programming languages/tooling, it works flawlessly.

I use Pipx (https://github.com/pypa/pipx) to install python thingies (such as yt-dlp) as a cli. Go and Rust handle binaries in their languages beautifully and without issues.