![]() ![]() This was important from earlier.īy setting up versioneer to listen to git tags, and using git-version-bump to automate semver bumps of git tags, then github-release to convert git tags into GitHub Releases, which then trigger a GitHub Action to publish to PyPI, you can publish a new version of your package with just two git commands. Within the scope of a running action, it is a git context. Your PyPI username and password are stored as GitHub secrets. This action is triggered when a GitHub release is created. When you setup an Action on a Python repo, it’s suggested that you could setup an action to publish to PyPI. GitHub Actions are a now public feature which makes continuous deployment an integrated feature of GitHub. This uploads local tags to GitHub, using a custom API token setup for you within the command on first execution (including asking for your OTP). You can automate publishing git tags as GitHub release by installing the github-release gem, which gives you the git release command. They are associated to a git tag, but allow attaching artefacts, and releases appear on the top level page of a repo. Git tags do appear in GitHub’s web interface, but Releases are a richer experience. git-version-bump happens to be implemented in Ruby, but that doesn’t matter as long as you have Ruby installed on your operating system. You can get this functionality as git version-bump if you gem install git-version-bump to automate semantic version git tag bumps. Git tags can be manually edited using git tag, but you can install a custom command to help automate the process of implementing say, semantic versioning, by allowing you to specify “bump patch” or “bump major” and the tag is updated based on the current version. The implementation language of the executable doesn’t matter the interpreter used to run the executable is defined in the shebang. As of git v2.20.0, git help -all now lists these external commands. git-thing, it also works as git thing ( with a space rather than a hyphen). If you have an executable file in your PATH that starts with git-, e.g. Git can execute external commands as if they were git commands. Versioneer itself isn’t a package dependency of your package, it’s self-contained in a _versioneer.py file This will work within the context of git. If you pip install versioneer and versioneer install it into your package, you can get versioneer to query git directly to get the current tag. You could setup a yourpackage/_version_.py, which allows you to at have the version stored outside of setup.py, but you still need to read from that file.īut why define the version in a file when you can dynamically query it from a git tag? How can you get setup.py to understand the version? It doesn’t have to be defined directly as a parameter of setup(), but it must be declared. version must be declared in a package’s setup.py. In Python’s packaging ecosystem, versions are important. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |