pypi? #1
Comments
claui
added a commit
to claui/hancho
that referenced
this issue
Mar 20, 2024
This allows anyone to `python -m build` an sdist or wheel for Hancho. In particular, @aappleby should be able to use this config as-is if they choose to publish Hancho on PyPI. The original `hancho.py` remains standalone and independent, and can still be copied into project development trees as-is. If @aappleby puts hancho on PyPI, anyone will be able to install and update hancho via `pip install` or whatever dependency management system they like. It also helps system package maintainers to package Hancho for their distribution with little modification. As a PEP 517 build backend, I suggest poetry-core rather than setuptools because poetry-core specifically supports packaging single-file `*.py` modules that live in a project root directly, while the setuptools backend would have required a subdirectory. This makes sure that `hancho.py` remains a portable, self-contained script that doesn’t require PyPI, pip, or anything else, and can be copied anywhere you like. One real-life example of a working system package using the Poetry backend is the `hancho` AUR package. [1] [2] [3] Addresses aappleby#1. [4] [1]: https://aur.archlinux.org/packages/hancho [2]: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=hancho [3]: https://aur.archlinux.org/cgit/aur.git/tree/pyproject.toml.template?h=hancho [4]: aappleby#1
claui
added a commit
to claui/hancho
that referenced
this issue
Mar 20, 2024
This allows anyone to `python -m build` an sdist or wheel for Hancho. In particular, if @aappleby decides to put hancho on PyPI, they should be able to use this config as-is. Rationale: Making Hancho available on PyPI allows anyone to install and update Hancho via `pip install` or whatever dependency management system they like. This is mainly for people who prefer to keep `hancho.py` in a separate location on their `PATH` separately from their own development tree, and have it updatable via `pip`. Having a PEP-517-conformant `pyproject.toml` also allows system package maintainers to package Hancho for their distribution with little modification. Design: To keep aligned to Hancho’s project mission, this particular `pyproject.toml` is specifically designed to let `hancho.py` remain an independent standalone script in the project root. In other words, users will still be able to pick just the `hancho.py` file and copy it into their project development tree as-is, without caring about `pyproject.toml` or anything else if they prefer so. Implementation note: In contrast to other build backends like setuptools, which would have required `hancho.py` to go in a subdirectory that matches the package name, poetry-core supports building a package from a single-file `*.py` module even if it lives in a project root directly, i.e. next to `pyproject.toml`. This is to make sure that `hancho.py` remains a portable, self-contained script that doesn’t require PyPI, pip, or anything else, and can be copied as-is anywhere you like. One real-life example of a working system package using the Poetry backend is the `hancho` AUR package. [1] [2] [3] Addresses aappleby#1. [4] [1]: https://aur.archlinux.org/packages/hancho [2]: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=hancho [3]: https://aur.archlinux.org/cgit/aur.git/tree/pyproject.toml.template?h=hancho [4]: aappleby#1
|
Thanks for the PR, that'll help a lot. I'm not quite ready to upload things to PyPI - I've got some bugs I need to fix that will require rewriting how template expansion works, but after that I think I'll be close to a viable "beta" version. At that point I'll look into PyPI again. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This looks really interesting! Any chance you can put it on pypi so it can get updated automatically?
I may try using this to build CircuitPython. I've been looking for a simple build system for it that isn't make.
The text was updated successfully, but these errors were encountered: