gh-action-pypi-publish
build
Our great sponsors
gh-action-pypi-publish | build | |
---|---|---|
5 | 7 | |
836 | 659 | |
3.7% | 4.1% | |
8.1 | 9.2 | |
2 days ago | 11 days ago | |
Python | Python | |
BSD 3-clause "New" or "Revised" License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
gh-action-pypi-publish
-
PyPI new user and new project registrations temporarily suspended
> Recently I've seen someone on Reddit trying to automate the creation of PyPI projects through GitHub Actions. The person was complaining that the first deployment couldn't use an API key for that project since it didn't exist. So I'm not surprised some people are trying to do the same for malicious purposes.
Sorry for the tangent, but: you can do this now! If you use trusted publishing, you can register a "pending publisher" for a project that doesn't exist yet. When the trusted publisher (like GitHub Actions) is used, it'll create the project[1].
All of this is supported transparently by the official publishing action for GitHub Actions[2].
[1]: https://docs.pypi.org/trusted-publishers/creating-a-project-...
[2]: https://github.com/pypa/gh-action-pypi-publish
-
Publishing to PyPI via GitHub Action
In the documentation example, I see that the action yaml file contains the line uses: pypa/gh-action-pypi-publish@release/v1. I have never done this before and almost went with that, but I am not sure why the example shows v1 hardcoded, so I don't think I actually want this to happen. It doesn't seem to be well explained though, and the pypi-publish action repo was also quiet on this. Is this saying that it will create a release branch in my repo and call the release v1? Or how will this appear after I've done it? Will I have to manually change this v1 to v0.1.1 in the actions file AND the pyproject.toml?
-
"Even with --dry-run pip will execute arbitrary code found in the package's setup.py. In fact, merely asking pip to download a package can execute arbitrary code"
Yeah, you're uploading to PyPi in your pipeline, great. The custom github action still uses twine because the stdlib falls short on BASIC security. https://github.com/pypa/gh-action-pypi-publish/blob/unstable/v1/twine-upload.sh
-
Do you publish pypi source code to Github as well in the same form?
I never bothered with pypi myself but I hope the nudge into github actions helps you. I've found the following promising github action: https://github.com/pypa/gh-action-pypi-publish
- The Python Package Index is now a GitHub secret scanning integrator
build
- How can I download a software for my user automatically?
-
Underappreciated Challenges with Python Packaging
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
-
"Even with --dry-run pip will execute arbitrary code found in the package's setup.py. In fact, merely asking pip to download a package can execute arbitrary code"
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
-
'Python: Please stop screwing over Linux distros'
building wheels/sdists to upload or install: build
-
An Interactive Cheat Sheet That Just Gives You The Answer
python3 setup.py sdist bdist_wheel - no need for an sdist when building wheels, also I'd recommend using pypa/build instead.
-
How to Structure a Python AWS Serverless Project
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:
-
The future of Python build systems and Gentoo
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.
What are some alternatives?
git-filter-repo - Quickly rewrite git repository history (filter-branch replacement)
installer - A low-level library for installing from a Python wheel distribution.
amplify-preview-actions - This action deploys your AWS Amplify pull request preview for your public repository
setuptools - Official project repository for the Setuptools build system
git-repo-sync - Git Repo Sync enables you to synchronize code to other code management platforms, such as GitLab, Gitee, etc.
pyunifiprotect - Unofficial UniFi Protect Python API and CLI
trufflehog - Find and verify credentials
awesome-pyproject - An Awesome List of projects using the pyproject.toml Python configuration file.
release - Contains every things needed to release jenkins core from the jenkins infra project
pipx - Install and Run Python Applications in Isolated Environments
roadmap - GitHub public roadmap
serverless-project-example - Example Python project using AWS serverless stack