Our great sponsors
-
pip-audit
Audits Python environments, requirements files and dependency trees for known security vulnerabilities, and can automatically fix them
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
tox-poetry-installer
A plugin for Tox that lets you install test environment dependencies from the Poetry lockfile
-
-
-
self-contained-runnable-python-package-template
This is a template for creating self-contained, runnable python projects in the form of a tidy, structured, runnable python package
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
Google Fonts
Font files available from Google Fonts, and a public issue tracker for all things Google Fonts
-
-
emacs-python-exec-find
Discontinued Tracks down the correct Python tooling executables from your virtualenvs so you can glue the binaries to Emacs and delete code in init.el [Moved to: https://github.com/wyuenho/emacs-pet]
This is really nicely written; kudos to the author for compiling a great deal of information in a readable format.
If I can be forgiven one nitpick: Poetry does not use a PEP 518-style[1] build configuration by default, which means that its use of `pyproject.toml` is slightly out of pace with the rest of the Python packaging ecosystem. That isn't to say that it isn't excellent, because it is! But you the standards have come a long way, and you can now use `pyproject.toml` with any build backend as long as you use the standard metadata.
By way of example, here's a project that's completely PEP 517 and PEP 518 compatible without needing a setup.py or setup.cfg[2]. Everything goes through pyproject.toml.
[1]: https://peps.python.org/pep-0518/
[2]: https://github.com/trailofbits/pip-audit/blob/main/pyproject...
You can take this a step further and completely automate the release of your package. That means the tagging the publishing and the GitHub release notes.
I don't have a blog post but you can see the process on my personal project https://github.com/DontShaveTheYak/cf2tf
Check out the merged PR's and the GitHub actions.
I even do alpha releases to test pypi.
PyPi is adding support for GitHub OIDC for publishing packages soon, so there will be no need to generate API keys - you can just grant your GitHub Actions permissions to publish to PyPi.
https://github.com/pypi/warehouse/issues/10619
This is almost exactly how I set up python projects; it’s reassuring to see it set out in one place.
I started using tox-poetry-installer[1] to make tox pick up pinned versions from the lock file and reuse the private package index credentials from poetry.
[1] https://github.com/enpaul/tox-poetry-installer
I believe that Poetry does conform to PEP 518 (i.e. it specifies `[build-system]requires`), but not to the `dependencies` part of PEP 621 [1]. There are plans for this in the future though [2].
[1] https://peps.python.org/pep-0621/
[2] https://github.com/python-poetry/roadmap/issues/3
To that end, I've had good success with `replease-please`: https://github.com/googleapis/release-please . It's available as a GitHub Action and works out of the box very easily. It does tagging, publishing, editing the CHANGELOG, creating a release and more. Whatever you want it to, really, using a bool flag in the CI pipeline that triggers after a release-please release was made aka merged into main.
The title should be: How to create a "Python DISTRIBUTION package".
The term "python package" means something entirely different (or at the very least is ambiguous in a pypi/distribution context).
To add to the confusion, creating a totally normal, runnable python package in a manner that makes it completely self-contained such that it can be "distributed" in a standalone manner, while still being a totally normal boring python package, is also totally possible (if not preferred, in my view).
Shameless plug: https://github.com/tpapastylianou/self-contained-runnable-py...
The title should be: How to create a "Python DISTRIBUTION package".
The term "python package" means something entirely different (or at the very least is ambiguous in a pypi/distribution context).
To add to the confusion, creating a totally normal, runnable python package in a manner that makes it completely self-contained such that it can be "distributed" in a standalone manner, while still being a totally normal boring python package, is also totally possible (if not preferred, in my view).
Shameless plug: https://github.com/tpapastylianou/self-contained-runnable-py...
Sure it can. The pre-commit tool is just a framework for running multiple hooks at commit time against just the files which are modified in that commit. You can configure those hooks however you want.
You also don't have to run the hooks at pre-commit time. Just don't hook pre-commit into your checkout. The pre-commit tool can also be configured to run its checks at a different stages than, well, the pre-commit stage:
https://pre-commit.com/#top_level-default_stages
Not necessarily, it just depends on how invested you are in the CI/CD pipeline for any given project, your preferences regarding self-hosting vs. cloud, and the amount of time you have to dedicate to the subject.
Strictly speaking, any tool or set of tools that allow you to trigger building & deploying/publishing artifacts in response to source control commits can be used to build a CI/CD pipeline. One could write bash scripts linked to a cron job that pulls a remote repository every n minutes and then performs some scripted actions to integrate changes between branches before building & publishing the artifact to a local SFTP server.
If you prefer a more mature solution with better documentation however, there is a (non-exhaustive) list of CI/CD tools on this awesome-devops list:
https://github.com/wmariuss/awesome-devops#continuous-integr...
You could just use the same font as your body copy - "Atkinson Hyperligeible" with `line-height: 0.8` and remove the `font-size: .8rem;` from your `body` rule.
If you want to keep a similar style: https://fonts.google.com/?category=Handwriting
Also: https://www.pagecloud.com/blog/best-google-fonts-pairings
> Yes, if you ran poetry install you could get editable mode, but that requires every single end user of your package to install poetry and explicitly invoke a poetry install just for your package. And if someone else's package uses a different package builder, now they need to install and invoke that one. And on and on, and you end up with a six-hundred-line install script because of all the one-off "must install this developer's favorite package manager to use their package" stuff.
[1] https://peps.python.org/pep-0660/
[2] https://github.com/python-poetry/poetry/issues/34#issuecomme...
[3] https://www.reddit.com/r/Python/comments/t3p3ub/comment/hyum...
I initially had some problems, then I've written an emacs package[1] to fix all of them. And it's due to the course of writing this package made me realize just how bad pre-commit is from its UX, design to its entire premise.
[1]: https://github.com/wyuenho/emacs-python-exec-find
Related posts
- I developed a template for starting new Python projects! Features: Poetry, GitHub CI/CD, MkDocs, publishing to PyPi/Artifactory, Pytest, Tox, black and isort.
- How to Create Virtual Environments in Python
- Boring Python: dependency management (2022)
-
Pipenv VS instld - a user suggested alternative
2 projects | 9 Dec 2023
- Which scaffolding package should I use?