![]() ![]() Automated Release with Github Actionsīoth processes (Github release and publishing at PyPI) can be automated using Github actions. Otherwise you have to bump the release version up and repeat the process (in that case the world will not end either). Keep in mind that you can upload a specific semantic version just once to PyPI, thats why it’s important to test uploading the version when just starting out the deployment process for a new project. Our tools works perfectly fine! $ tihttp -H Īnd now that we are sure that everything works, it’s time to upload things to PyPI. $ twine upload -repository testpypi dist/* ![]() For testing purposes it’s convenient to upload the project to TestPyPI first. Now we have to register at PyPI before we can upload our project. The generated files can be found within the dist directory. To publish a python project at PyPI we have to package it by generating a source distribution (.tar.gz) and a wheel distribution (.whl). ![]() In the next section we will package our project and publish it at the Python Packaging Index (PyPI). I like to document the changes of the release in a CHANGELOG.md file.Īt last, we publish the release. We can add binaries if we release projects which use compiled languages or write release notes. We go to Releases □ Create a new release, and type the tag we wanna release. Now we browse our way to the Github repository and create a release. In this case we will tag the last commit and push it into the remote repo. We can also tag older commits when specifying the commit ID (example: git tag v1.1.0 c52e686). The git tag command tags by default the last commit. We can use lightweight or annotated tags which contain extra metadata. We point to the commit we want to release by tagging it. We use the former and call our first release v0.1.0. Developers pick either semantic versioning or calendar versioning as versioning scheme. Then we can then make a new release as we gathered enough fixes/features. This way we keep the main line always in a releasable state. Tag our project and stick thereby to a versioning schemeĭepending on the kind/size of a project developers use Git branching workflows when working as a team but for smaller projects it’s sufficient to work on the main line and create only branches when introducing features that might affect the stability of the project.$ pip install īut Python packages are usually installed from the Python Packaging Index (PyPI) with a simple name you can remember like $ pip install tihttpīut how do we release our project so other can download it conveniently from the Python packaging index? We make sure that our main line is in releasable state and then we ContentsĪs stated in previous posts our tiny HTTP client can now be downloaded from Github and installed via pip. The code of this post can be found on Github (see here). This is part 8 of the multi-part series “The Evolution of a Script”. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |