Choosing a better build backend than setuptools

[Avasam]

Following #101, switching the build backend is now as easy as literally changing 2 lines.

You may want to consider a different backend than setuptools, which is literally the slowest, biggest (in size) and least maintained amongst all options available: https://packaging.python.org/en/latest/guides/tool-recommendations/#build-backends + https://docs.astral.sh/uv/concepts/build-backend/#choosing-a-build-backend

I highly suggest you read the link above, as well as the following table I compiled: python/typeshed#13622 (review)
but tl-dr: This is a pure-python project, so plugins are a non-offering. Performance, footprint and maintenance are the only real concerns.

I'd personally recommend uv_build as it would integrate very will with #99 (the uv build frontend comes with its own integrated build backend pre-installed, so it doesn't have to install it from PyPI at build time !
uv is basically an all-in-one extremely efficient package management tool that also comes with commands to build+publish. It's literally as easy as uv sync && uv build && uv publish, replacing pip, venv, build, wheel and twine packages/tools. Great error messages and documentation too !

If you wanna keep your current workflow AND mind the uv_build backend footprint (it's honestly still faster despite a bigger initial download), then I'd recommend flit-core, it is the smallest and fastest pure-python backend, and is a bit more restrictive/pedantic.

---

Side note, you also now have 3 valid options of handling versioning:

1. Current pywinctl.__version__ that is read by build backend. Requires pywinctl to be importable at build time (dynamic project.version)
2. VCS based (build backend uses git to see if the current commit match an exact git tag. This is great to automate deployment and version bump simply by pushing a git tag, rather than having the version be found in source. (dynamic project.version)
3. Write the version to pyproject.toml instead (static project.version)

* To keep pywinctl.__version__ existing, option 2 and 3 require filling it in at runtime using packaging metadata (through the importlib module)

[Kalmat]

Thank you so much for your suggestion.

Sorry, but I have no knowledge on these tools to even opinate, so I will need a little bit of help from you. If your recommendation is uv_build, it's ok on my side. If I understood correctly, I should install uv on python, then use it to build and publish the package, right?

This is what I use to build and publish my projects (these are .bat files inside the package folder).

Make Wheel:
python setup.py bdist_wheel

Prepare to upload to PyPi:
python setup.py sdist

Upload to PyPi:
twine upload dist/*.whl

So, using these new tools you propose, how should I perform these actions? Is it as easy as this: uv sync && uv build && uv publish?

Apart from this, I guess using uv will change the way any user prepares the dev environment (I mean, pip -r requirements.txt will no longer work, right?).

You mention an issue regarding versioning (currently version is taken from __init__.py file, where it is hardcoded), what do you think is the best solution? Could I use this: uv sync && uv build 0.4.2 && uv publish --username __token__?

Is there anything else I should take into account when switching to uv_build or flit-core?

Too many questions, I know, sorry.

[Kalmat]

I've been reading about uv a little (still a lot to investigate. Impressive work you did when comparing backends, congrats!). I didn't find any GUI, since it seems to be a CLI-focused tool... Do you think a GUI for uv (perhaps for some other tools too, from a multi-backend perspective) could be interesting?

[Avasam]

You mention an issue regarding versioning (currently version is taken from __init__.py file, where it is hardcoded)

I think the way you're doing it right now is fine. It's an old standard but a well supported one across build backends from what I could find. I only mentioned the other options for the sake of completeness.

---

If your recommendation is uv_build, it's ok on my side. If I understood correctly, , then use it to build and publish the package, right?
Is there anything else I should take into account when switching to uv_build or flit-core?

Literally only your personal preferences (and I'll just make sure project versioning does keep working the way you're already doing it)

---

I should install uv on python

One of the (many) big strength of uv, is that it's not written in Python. So there's no need to manually bootstrap your Python environment ! You can develop Python projects without any global Python install. "Python" itself becomes sort of a dev dependency ! It makes it super easy to swap Python environment to different versions too.

https://docs.astral.sh/uv/getting-started/installation/

uv sync will automatically download, install and cache a Python executable (defaults to latest supported in pyproject.toml, but you can specify), create a virtual environment at .venv, remove unused dependencies, and install (download + cache) dependencies specified in pyproject.toml (including dev dependencies)

uv run some_script_or_app by default runs uv sync AND runs the command in your venv (no need to manually activate it anymore !)

uv pip is a pip-like interface for only installing packages, without looking at pyproject.toml at all.

[Avasam]

Build frontends & Publishing

(with PEP-517 in place, this now has nearly no effect on this issue I opened [except for uv pre-bundling uv-build], but since you brought it up, let me help you disentangle some concepts)

python setup.py

Note that calling setup.py directly as a srcipt has loooong been deprecated and is actively discouraged. Setuptools has even been removing functionality from this as time goes ! Consider setup.py like a dynamic configuration file for setuptools.
https://setuptools.pypa.io/en/latest/deprecated/commands.html#:~:text=Warning

https://peps.python.org/pep-0517/ is all about separating build frontends (the CLI tools) from the build backends (the code that builds and bundles your code). As well as making build isolated (its own set of dependencies)

Your build frontend (build, pip, pip wheel, uv, poetry, hatch, pipenv, pdm, flit, etc.) calls the build backend (right now setuptools.build_meta, and that happens to run setup.py, if it exists, to get dynamic configs and merge it with pyproject.toml.

---

I guess using uv will change the way any user prepares the dev environment

I've already updated your documentation !
https://github.com/Kalmat/PyWinCtl#using-this-code-

PyWinCtl/README.md

Lines 255 to 261 in d9ea006

	Be sure you install all dev dependencies by running:
	uv sync
	or
	python -m venv .venv
	python -m pip install -e . --group=dev

These are recommendations for novice-to-medium Python developers. Advanced users can use whatever the build frontend and package manager they want now.

---

This is what I use to build and publish my projects (these are .bat files inside the package folder).
[...]
I didn't find any GUI, since it seems to be a CLI-focused tool... Do you think a GUI for uv (perhaps for some other tools too, from a multi-backend perspective) could be interesting?

I've personally never seen a GUI tool to publish to PyPI, but I've also only seen CD-integrations and have manually published myself after I started using uv

In fact, notice how there's no more setup.py in this project !

You should use either:

• pip wheel: pip wheel (only produces wheels, no sdist, no extra build tooling other than pip)
• build: python -m build (produces both sdist + wheel by default, requires having python build installed)
• uv: uv build (produces both sdist + wheel by default, requires having uv installed)

With pip wheel (wheels only)

# Upgrading your own tooling
python -m pip install --upgrade pip twine
# Building
python -m pip wheel
# Publishing
python -m twine upload dist/*

With pip + build (sdist + wheels)

# Upgrading your own tooling
python -m pip install --upgrade pip twine build
# Building
python -m pip build
# Publishing
python -m twine upload dist/*

With uv (sdist + wheels)

# Upgrading your own tooling
uv self update
# Building
uv build
# Publishing
uv publish

It all does the same in the end (except pip wheels missing sdist)
Also notice I never installed project dependencies. (no uv pip install, no uv sync, no pip install)

---

Prepare to upload to PyPi:
python setup.py sdist

Notice you were building sdists, but you never published them. It's ok though, you don't strictly need them as a pure-python project.

[Avasam]

PS: uv-build is fully static metadata (for now: astral-sh/uv#14561)

I'll make 2 PRs, 1 with flit, 1 with uv, you can choose which you prefer.

[Kalmat]

Wow! What I know is a drop, what I ignore is an ocean!! I will need some time to properly assimilate all this information. Thank you!

I managed to install uv and play with it a little. I've seen it has direct integration with PyCharm (which is the IDE I use), so I think that I will choose uv (not completely sure by now until I understand all the info you provided first).

Just one comment for now:

I've personally never seen a GUI tool to publish to PyPI, but I've also only seen CD-integrations and have manually published myself after I started using uv

I was thinking of a full frontend for uv and other build and publish tools, not only for publishing to PyPi. Graphically helping users to:

• create projects and environments
• manage dependencies
• generate required docs (like pyproject.toml)
• guided help to import/migrate projects from other backends or outdated/deprecated environments
• manage versions and releases
• build and publish packages
• etc., etc.

Most likely this seems interesting to me only because I know nothing about these tools, but perhaps it could also be helpful for others like me... what do you think?

[Kalmat]

PS: I just saw this:

I've already updated your documentation !

HAHAHAHA! You are a crack!!! (in Spanish, "crack" refers to an outstanding person, usually but not only, referred to footballers like Messi or Christiano Ronaldo ;)

[Avasam]

Oh btw if you use PyCharm, they've now integrated ty as their language server+type checker.
ty is also done by Astral, same team as Ruff and uv.

It's still in early phases though, it's still missing some features I need. But it would be more relevant than pyright (used by Pylance in VSCode) for you.
Something to keep an eye out for the future.

Astral really revolutionized the Python tooling ecosystem.

[Kalmat]

Trying ty on PyCharm right now! Looks great for typing! Isn't it? A great help in my case (I still struggle a lot with typing, TBH)

[Avasam]

I opened the following 2 for comparison:

• flit_core build backend #107
• uv_build build backend #108