EzPyPI
Definitions
PEP 440 – Version Identification and Dependency Specification
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
- “Projects“ are software components that are made available for integration. Projects include Python libraries, frameworks, scripts, plugins, applications, collections of data or other resources, and various combinations thereof. Public Python projects are typically registered on the Python Package Index.
- “Releases“ are uniquely identified snapshots of a project.
- “Distributions“ are the packaged files which are used to publish and distribute a release.
- “Build tools“ are automated tools intended to run on development systems, producing source and binary distribution archives. Build tools may also be invoked by integration tools in order to build software distributed as sdists rather than prebuilt binary archives.
- “Index servers“ are active distribution registries which publish version and dependency metadata and place constraints on the permitted metadata.
- “Publication tools“ are automated tools intended to run on development systems and upload source and binary distribution archives to index servers.
- “Installation tools“ are integration tools specifically intended to run on deployment targets, consuming source and binary distribution archives from an index server or other designated location and deploying them to the target system.
- “Automated tools“ is a collective term covering build tools, index servers, publication tools, integration tools and any other software that produces or consumes distribution version and dependency metadata.
Setup Environments
Prerequisites
Git and Github
Install git
on your operating system and setup the github account.
Python
TestPyPI and PyPI
Name your project and distribution.
Python Naming Convention
How to Write Beautiful Python Code With PEP 8
PEP 423 – Naming conventions and recipes related to packaging
We need to name the project and the distribution.
For this project, the project name is EzPyPI
.
For this distribution, the distribution name of the package is ezpypi
. To simplify, I will use distribution name.
- A distribution is the integration of all of your packages.
For the packages inside your distribution, they can have their own names.
Why don’t we use the same name for the project and distribution?
In order to comply with the naming convention of PEP 423, the distribution name should be like lower_with_under
.
For making our project more attractive and clear, we would better to give the project capital words, such as:
- NumPy project has the distribution name numpy
- SciPy project has the distribution name scipy
- TensorFlow project has the distribution name tensorflow
You can also give your project and distribution the same name, such as:
But remember, for this project,
- the project name is
EzPyPI
- the distribution name is
ezpypi
Check if your distribution name available
Next, we need to check if the distribution name available in TestPyPI and PyPI.
Let’s search for the distribution name on the two websites.
Good news! Our distribution name ezpypi
is available.
Create a repository for the project
If you want to build a large project, you probably need a GitHub account name as the same as your project name. Here I assume you are a individual developer who is willing to put the project under the person GitHub repository.
Modern projects need version control. So we are going to make a brand new repository for this project EzPyPI
.
Login with your account on GitHub.
- Repository name: your project name
- Description (optional): description for your project
Initialize this repository with:
Add a README file
Add .gitignore: Python
Choose a license: MIT License
If you’d like to choose a different license, click on Licensing a repository for more information.
Click on Create repository
Click on Code
, then copy the command for cloning your GitHub repository to your computer.
Project Structure
Best Practices for Python Project Structure
Structuring Your Project
Python Application Layouts: A Reference
samplemod
Packaging Python Projects
In short, your project structure should follow the structure like these:
Installable Single Package
1 | project_name/ |
Project EzPyPI
will has the project structure as the following:
1 |
Git clone your project
Let’s find a directory to put on our project. I will choose ~/Desktop
Change directory to ~/Desktop
. Then clone your GitHub repository.
1 | cd ~/Desktop |
If you don’t have a GitHub CLI, you can clone your repository through git clone
:
1 | git clone git@github.com:ZacksAmber/EzPyPI.git |
Make a directory for distribution
Change directory to your project directory. Then make a directory for your distribution with the distribution name.
1 | cd EzPyPI |
You can check your project structure through command tree.
1 | tree |
The latest project structure:
1 | . |
Virtual Environment Configuration
Make an Python virtual environment for your project
Make an virtual environment through python3 -m venv/[project name]
.
This command will first make a directory called venv
under the project directory EzPyPI
.
Then make an Python virtual environment under directory venv
with the directory name EzPyPI
1 | python3 -m venv venv/EzPyPI |
The latest project structure:
1 | tree -L 4 # -L 4 to restrict the max directory levels as 4 |
1 | . |
Remember the path of activate
, it is located in [project directory]/venv/[venv directory]/bin/activate
Activate your venv
Activate your venv through source [project directory]/venv/[venv directory]/bin/activate
1 | source venv/EzPyPI/bin/activate |
As you can see, once you activate your venv, the user prefix will change to your venv name.
Deactivate your venv
If you don’t wan to use this venv again, type the following command:
1 | deactivate |
Upgrade and Install required Python tools
Key terms
- the Python Packaging Index is a public repository of open source licensed packages made available for use by other Python users
- distutils is the original build and distribution system first added to the Python standard library in 1998. While direct use of distutils is being phased out, it still laid the foundation for the current packaging and distribution infrastructure, and it not only remains part of the standard library, but its name lives on in other ways (such as the name of the mailing list used to coordinate Python packaging standards development).
- setuptools is a (largely) drop-in replacement for distutils first published in 2004. Its most notable addition over the unmodified distutils tools was the ability to declare dependencies on other packages. It is currently recommended as a more regularly updated alternative to distutils that offers consistent support for more recent packaging standards across a wide range of Python versions.
- wheel (in this context) is a project that adds the
bdist_wheel
command to distutils/setuptools. This produces a cross platform binary packaging format (called “wheels” or “wheel files” and defined in PEP 427) that allows Python libraries, even those including binary extensions, to be installed on a system without needing to be built locally.
Our Practice
Activate your venv if you deactivate it.
Using pip
to install or upgrade the three packages: setuptools
, wheel
, and twine
.
1 | pip install setuptools wheel twine --upgrade |
List all of your current packages under the venv.
1 | pip list |
Building and packaging the project
Creating a test directory
tests/
is a placeholder for test files. Leave it empty for now.
1 | mkdir test/ |
The latest project structure:
1 | tree -L 2 # -L 2 to restrict the max directory levels as 2 |
1 | . |
Creating pyproject.toml
Official Guides
pyproject.toml
tells build tools (like pip and build) what is required to build your project. This tutorial uses setuptools, so open pyproject.toml
and enter the following content:
1 | [build-system] |
build-system.requires
gives a list of packages that are needed to build your package. Listing something here will only make it available during the build, not after it is installed.build-system.build-backend
is the name of Python object that will be used to perform the build. If you were to use a different build system, such as flit or poetry, those would go here, and the configuration details would be completely different than the setuptools configuration described below.- See PEP 517 and PEP 518 for background and details.
Our Practice
Create pyproject.toml
1 | touch pyproject.toml |
Add the above content to pyproject.toml
then save the file.
The pyproject.toml
for this project is:
1 | [build-system] |
The latest project structure:
1 | tree -L 2 # -L 2 to restrict the max directory levels as 2 |
1 | . |
Configuring metadata
Official Guides
Building and packaging the project
Configuring setup() using setup.cfg files
Packaging and distributing projects
There are two types of metadata: static and dynamic.
- Static metadata (
setup.cfg
): guaranteed to be the same every time. This is simpler, easier to read, and avoids many common errors, like encoding errors. - Dynamic metadata (
setup.py
): possibly non-deterministic. Any items that are dynamic or determined at install-time, as well as extension modules or extensions to setuptools, need to go intosetup.py
.
Static metadata (setup.cfg
) should be preferred. Dynamic metadata (setup.py
) should be used only as an escape hatch when absolutely necessary. setup.py
used to be required, but can be omitted with newer versions of setuptools and pip.
setup.cfg
is the configuration file for setuptools. It tells setuptools about your package (such as the name and version) as well as which code files to include. Eventually much of this configuration may be able to move to pyproject.toml
.
Open setup.cfg
and enter the following content. Change the name
to include your username; this ensures that you have a unique distribution name and that your package doesn’t conflict with packages uploaded by other people following this tutorial.
1 | [metadata] |
There are a variety of metadata and options supported here. This is in configparser format; do not place quotes around values. This example package uses a relatively minimal set of metadata
:
name
is the distribution name of your package. This can be any name as long as it only containsletters
,numbers
,_
, and-
. It also must not already be taken on pypi.org. Be sure to update this with your username, as this ensures you won’t try to upload a package with the same name as one which already exists.version
is the package version. See PEP 440 for more details on versions. You can usefile
: orattr
: directives to read from a file or package attribute.author
andauthor_email
are used to identify the author of the package.description
is a short, one-sentence summary of the package.- long_description is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from
README.md
(which is a common pattern) using thefile
: directive. long_description_content_type
tells the index what type of markup is used for the long description. In this case, it’s Markdown.url
is the URL for the homepage of the project. For many projects, this will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting service.project_urls
lets you list any number of extra links to show on PyPI. Generally this could be to documentation, issue trackers, etc.classifiers
gives the index and pip some additional metadata about your package. In this case, the package is only compatible with Python 3, is licensed under the MIT license, and is OS-independent. You should always include at least which version(s) of Python your package works on, which license your package is available under, and which operating systems your package will work on. For a complete list of classifiers, see https://pypi.org/classifiers/.
In the options
category, we have controls for setuptools itself:
package_dir
is a mapping of distribution names and directories. An empty distribution name represents the “root package” — the directory in the project that contains all Python source files for the package — so in this case thesrc
directory is designated the root package.packages
is a list of all Python import packages that should be included in the distribution package. Instead of listing each package manually, we can use thefind
: directive to automatically discover all packages and subpackages andoptions.packages.find
to specify the package_dir to use. In this case, the list of packages will beexample_package
as that’s the only package present.python_requires
gives the versions of Python supported by your project. Installers like pip will look back through older versions of packages until it finds one that has a matching Python version.
setup.py
is the build script for setuptools. It tells setuptools about your package (such as the name and version) as well as which code files to include.
Open setup.py
and enter the following content. Change the name
to include your username; this ensures that you have a unique distribution name and that your package doesn’t conflict with packages uploaded by other people following this tutorial.
1 | import setuptools |
setup()
takes several arguments. This example package uses a relatively minimal set:
name
is the distribution name of your package. This can be any name as long as it only containsletters
,numbers
,_
, and-
. It also must not already be taken on pypi.org. Be sure to update this with your username, as this ensures you won’t try to upload a package with the same name as one which already exists.version
is the package version. See PEP 440 for more details on versions.author
andauthor_email
are used to identify the author of the package.description
is a short, one-sentence summary of the package.- long_description is a detailed description of the package. This is shown on the package detail page on the Python Package Index. In this case, the long description is loaded from
README.md
, which is a common pattern. long_description_content_type
tells the index what type of markup is used for the long description. In this case, it’s Markdown.url
is the URL for the homepage of the project. For many projects, this will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting service.project_urls
lets you list any number of extra links to show on PyPI. Generally this could be to documentation, issue trackers, etc.classifiers
gives the index and pip some additional metadata about your package. In this case, the package is only compatible with Python 3, is licensed under the MIT license, and is OS-independent. You should always include at least which version(s) of Python your package works on, which license your package is available under, and which operating systems your package will work on. For a complete list of classifiers, see https://pypi.org/classifiers/.package_dir
is a dictionary with distribution names for keys and directories for values. An empty distribution name represents the “root package” — the directory in the project that contains all Python source files for the package — so in this case thesrc
directory is designated the root package.packages
is a list of all Python import packages that should be included in the distribution package. Instead of listing each package manually, we can usefind_packages()
to automatically discover all packages and subpackages under package_dir. In this case, the list of packages will beexample_package
as that’s the only package present.python_requires
gives the versions of Python supported by your project. Installers like pip will look back though older versions of packages until it finds one that has a matching Python version.
There are many more than the ones mentioned here. See Packaging and distributing projects for more details.
Our Practice
Specifications
PEP 440 – Version Identification and Dependency Specification
We are going to use Sequence-based scheme for versioning.
Finial releases:
1 | MAJOR.MINOR[.MICRO] |
Development releases:
1 | MAJOR.MINOR[.MICRO].devN |
This project does need setup.py
. So we will only create a setup.cfg
for setuptools.
Make setup.cfg
then copy and edit the above template.
1 | touch setup.cfg |
The latest project structure:
1 | tree -L 2 |
1 | . |
The configuration meta data for project EzPyPI
are:
1 | [metadata] |
Create CHANGELOG.md
Changelog: Changelog (or release notes) helps developers to stay up to date with project changes and helps migrating to new versions.
Semantic Versioning 2.0.0
As you can see, we need three files README.md
, CHANGELOG.md
, and LICENSE
.
We already have README.md
and LICENSE
. So let’s create CHANGELOG.md
.
1 | touch CHANGELOG.md |
The content inside CHANGELOG.md
is:
1 | # Changelog |
The latest project structure:
1 | tree -L 2 |
1 | . |
Including other files
Official Guides
Including other files
Including files in source distributions with MANIFEST.in
The files listed above will be included automatically in your source distribution. If you want to control what goes in this explicitly, see Including files in source distributions with MANIFEST.in.
The final built distribution will have the Python files in the discovered or listed Python packages. If you want to control what goes here, such as to add data files, see Including Data Files from the setuptools docs.
Our Practice
1 | touch MANIFEST.in |
Edit the MANIFEST.in
.
The content inside MANIFEST.in
is:
1 | include MANIFEST.in |
The latest project structure:
1 | tree -L 2 |
1 | . |
Create directory doc
Let’s create directory doc
for future use.
1 | mkdir doc |
The latest project structure:
1 | tree -L 2 |
1 | . |
Add the basic Python scripts
Create __init__.py
Create __init__.py
into your package directory.
1 | touch ezpypi/__init__.py |
Add the following code:
1 | from ezpypi.core import EzPyPI |
Create core.py
Create core.py
into your package directory.
1 | touch ezpypi/core.py |
Add the following code:
1 | class EzPyPI: |
The latest project structure:
1 | tree -L 2 |
1 | . |
Local Installation
1 | pip install . |
Validation
List the Python packages under your venv.
1 | pip list |
Now we can try to import ezpypi
in different directories.
Change directory to venv
.
1 | cd venv |
1 | import ezpypi |
Exit Python console.
1 | exit() |
Change directory to the last one.
1 | cd .. |
1 | . |
since we successfully validate the package, we remove the .dev0
in the 3rd line of setup.cfg
.
The latest setup.cfg
should like:
1 | [metadata] |
Working with GitHub
Our package works well!
So let’s push the package to GitHub with main
branch and maintenance/0.0.x
branch main
View current branch
List the available branches and your current branch.
1 | git branch |
As you can see, I only have one branch – main
.
View status
Press q
to quit.
1 | git status |
Git reminds us that we need to commit the changes before uploading.
Add and Commit
Add all objects then commit them.
1 | git add . |
Push
Push the local repository to GitHub with branch main
1 | git push |
Check our GitHub repository EzPyPI
with the branch main
.
Check the git status
1 | git status |
Everything is up to date!
branch maintenance
Make an maintenance branch
17.1. Branches
3.2 Git Branching - Basic Branching and Merging
Let’s make a maintenance branch for our project with the name maintenance/0.0.x
.
1 | git checkout -b maintenance/0.0.x |
1 | git status |
Now we are on branch maintenance/0.0.x
and everything is the same as them on branch main
.
Push
Since nothing to commit, we are ready to push branch maintenance/0.0.x
to GitHub.
git push -u origin [branch]
: Useful when pushing a new branch, this creates an upstream tracking branch with a lasting relationship to your local branch
1 | git push -u origin maintenance/0.0.x |
Check branch maintenance/0.0.x
on GitHub.
Click on main
.
On the list, click on maintenance/0.0.x
.
Everything is up to date!
Switch branch
Git Branches: List, Create, Switch to, Merge, Push, & Delete
To list all of the local branches:
1 | git branch |
To switch to another branch:
git checkout [branch name]
1 | git checkout main |
Update your project
In the future, you should yield the following steps to update your project:
- Assume your latest distribution version is
0.0.1
- Switch to branch
maintenance/0.0.x
through commandgit checkout maintenance/0.0.x
- Modify your project version from
0.0.1
to0.0.2.devN
insetup.cfg
- Every time when the project works well with your latest changes:
git add [changes]
git commit -m 'Update/Fix xx features. ver=x.x.x.devN'
- When everything pass the unit test and integration test, remove
.devN
insetup.cfg
. Then push the project to GitHub with branchmaintenance/0.0.x
. - Release the new project to TestPyPI. Then test your project by your users.
- If no bug, switch branch to main through command
git checkout main
. - Merge your changes from
maintenance/0.0.x
tomain
through commandgit merge maintenance/0.0.x
. Then push the project to GitHub with branchmain
. - Release the new project to PyPI
Generating distribution archives
Since we successfully tested the package, it’s time to generate distribution archives for uploading the distribution to TestPyPI PyPI.
Check the git status and checkout to maintenance/0.0.x
1 | git status |
The next step is to generate distribution packages for the package. These are archives that are uploaded to the Python Package Index and can be installed by pip.
Make sure you have the latest version of PyPA’s build installed:
1 | pip install --upgrade build |
Tip: If you have trouble installing these, see the Installing Packages tutorial.
Now run this command from the same directory where pyproject.toml
is located:
1 | python3 -m build |
This command should output a lot of text and once completed should generate two files in the dist directory:
1 | ls -l dist |
The latest project structure:
1 | tree -L 2 |
1 | . |
The tar.gz
file is a source archive whereas the .whl
file is a built distribution. Newer pip versions preferentially install built distributions, but will fall back to source archives if needed. You should always upload a source archive and provide built archives for the platforms your project is compatible with. In this case, our example package is compatible with Python on any platform so only one built distribution is needed.
Uploading the distribution archives to TestPyPI
Finally, it’s time to upload your package to the TestPyPI!
To securely upload your project, you’ll need a PyPI API token. Create one at https://test.pypi.org/manage/account/#api-tokens, setting the “Scope” to “Entire account”. Don’t close the page until you have copied and saved the token — you won’t see that token again.
Now that you are registered, you can use twine to upload the distribution packages. You’ll need to install Twine:
1 | python3 -m pip install --upgrade twine |
Once installed, run Twine to upload all of the archives under dist
:
1 | python3 -m twine upload --repository testpypi dist/* |
You will be prompted for a username and password. For the username, use __token__
. For the password, use the token value, including the pypi-
prefix.
After the command completes, you should see output similar to this:
Once uploaded your package should be viewable on TestPyPI, for example, https://test.pypi.org/project/example-pkg-YOUR-USERNAME-HERE
To view our package on TestPyPI
Now search for ezpypi
on TestPyPI
Installing your newly uploaded package
Check your local installed packages and grep ezpypi
:
1 | pip list | grep ezpypi |
Uninstall ezpypi
1 | pip uninstall ezpypi |
You can use pip to install your package and verify that it works. Create a virtual environment and install your package from TestPyPI:
1 | pip install -i https://test.pypi.org/simple/ ezpypi==0.0.1 |
Validation:
Change directory to venv
1 | cd venv |
You can test that it was installed correctly by importing the package. Make sure you’re still in your virtual environment, then run Python:
1 | python3 |
1 | import ezpypi |
1 | exit() |
Change directory to your project directory
1 | cd .. |
Uploading the distribution archives to PyPI
Since we successfully tested the package from Test PyPI, it’s time to upload the package to PyPI.
Check the git status and checkout to maintenance/0.0.x
1 | git status |
Run Twine to upload all of the archives under dist:
1 | python3 -m twine upload --repository pypi dist/* |
View our project on PyPI
Search for ezpypi
on PyPI
Installing your newly uploaded package
Check your local installed packages and grep ezpypi
:
1 | pip list | grep ezpypi |
Uninstall ezpypi
1 | pip uninstall ezpypi |
You can use pip to install your package and verify that it works. Create a virtual environment and install your package from PyPI:
1 | pip install ezpypi==0.0.1 |
Validation:
Change directory to venv
1 | cd venv |
You can test that it was installed correctly by importing the package. Make sure you’re still in your virtual environment, then run Python:
1 | python3 |
1 | import ezpypi |
1 | exit() |
Change directory to your project directory
1 | cd .. |
One more Example
We made it! And now we want to improve our project:
- update docs
- add more dependencies
- update the project
- add git flow chart
- make more packages to make the project powerful
- make the packages organized
BUG WARNING: all of the following version should be 0.1.0
instead of 0.2.0
.
PyPI and TestPyPI do not support downgrade your version. So make sure your version be continuous.
Git
But we need checkout to maintenance/0.0.x
since we’re updating the stable distribution.
Remember, any update may causing unpredictable bugs. That’s why we need version control!
1 | git status |
Since we are updating the distribution, rather than fixing bugs, we will update the version in setup.cfg
from 0.0.1
to 0.2.0.dev0
.
Commit this change.
1 | git status |
Update Docs
Since we have more information now, it’s time to update the docs.
README.md
The README.md is displayed on the your project home page of TestPyPI and PyPI, since long_description = file: README.md
is in setup.cfg
CHANGELOG.md
The CHANGELOG.md should be updated every time when you make or want to make an update for your project.
setup.cfg
Change it as your needs. For example, we can switch the classifiers
from Development Status :: 1 - Planning
to Development Status :: 2 - Pre-Alpha
.
Add files to doc
Add extra files to doc, such as an README.md
1 | # EzPyPI Documentation |
Notice: If you don’t add any file to doc/
, you cannot push an empty directory to GitHub.
Add workflows
Before we get start, let’s push the current commit to GitHub.
1 | git status |
1 | git push |
Flowcharts or mind map can help us better understand users’ requirements and design your program.
Visit https://draw.io and click on GitHub.
Click on Create New Diagram
For example, under Software
, select Git flow 3
Under extension, select .svg
Rename it then click on Create
Login with GitHub account.
Choose doc/
directory. Then click on OK
Leave the commit message as default.
a simple git branching model (written in 2013)
OneFlow – a Git branching model and workflow
Once you finished, save it and add a commit message.
Check the Git flow on our GitHub.
Check GitHub status.
1 | git remote update |
Check git local status
1 | git status |
Since we save the git flow chart on GitHub, we need to synchronize the local git objects.
1 | git pull |
List the directory doc
As we can see, we have the Git flow chart on the local machine.
Add dependencies
Edit your setup.cfg
.
Under the install_requires
, add more packages.
For example:
1 | install_requires = |
Change your Project Structure
Since our project has the most basic project structure.
We’d like to update it and make it more organized and extendable.
Make sure your are on the root directory of your project directory.
1 | pwd |
Add a package directory called src
as the distribution directory. Therefore, our three important directories are:
EzPyPi
: the Project DirectoryEzPyPi/src
: the Distribution Directory, which is the root directory for your source code.- Python recommends to use
src
as the Distribution Directory
- Python recommends to use
EzPyPi/src/ezpypi
: the Main Package Directory
Make a directory called src.
1 | mkdir src |
Move the Main Package Directory to the Distribution Directory:
1 | mv ezpypi src |
The latest project structure:
1 | tree -L 2 |
1 | . |
Then we need to update setup.cfg
: replace .
with src
package_dir
: line 39where
: 54
The latest setup.cfg
for project EzPyPI
is:
1 | [metadata] |
Add core directory
You can use directory core
to store your core code. core
will be a package of your project.
mkdir src/[your main package directory]/core
1 | mkdir src/ezpypi/core |
Move core.py to directory core
1 | mv src/ezpypi/core.py src/ezpypi/core |
rename core.py
to any name since we already have directory core
, such as main
1 | mv src/ezpypi/core/core.py src/ezpypi/core/main.py |
Edit main.py
1 | def main(): |
Add __init__.py
for package core
.
Then add from .main import main
to __init__.py
1 | echo 'from .main import main' > src/ezpypi/core/__init__.py |
Update __init__.py
Then we need to update __init__.py
in directory src/ezpypi/__init__.py
1 | from .core import * |
Test
Update the version in setup.cfg
from version = 0.2.0.dev0
to version = 0.2.0.dev1
since we make a big change.
Uninstall the package then install it locally.
Go to directory venv
and test the package.
1 | cd venv |
1 | import ezpypi |
Notice our distribution ezpypi
now has a package core
.
1 | ezpypi.core.main() |
Change directory to your project directory
1 | cd .. |
TestPyPI
Make sure your are under maintenance/0.0.x
Git
Update the version in setup.cfg
from version = 0.2.0.dev1
to version = 0.2.0
since the package is stable now.
1 | git status |
1 | git add . |
Build distribution
Now run this command from the same directory where pyproject.toml
is located:
1 | python3 -m build |
List the files inside directory dist
.
1 | ls -l dist |
Upload distribution to TestPyPI
Run Twine to upload all of the archives end with 0.2.0
under dist:
1 | python3 -m twine upload --repository testpypi dist/*0.2.0* |
PyPI
Git
Merge your git branch.
1 | git status |
If you meets git merge CONFLICT, check here
We can fix it manually.
Since we have fixed the merge CONFLICT, we add the file and commit it.
1 | git add setup.cfg |
Merge again.
1 | git merge maintenance/0.0.x |
1 | git push |
Upload distribution to TestPyPI
Run Twine to upload all of the archives end with 0.2.0
under dist:
1 | python3 -m twine upload --repository pypi dist/*0.2.0* |
Validation
Uninstall the local package.
Install the latest version from PyPI.
1 | pip install ezpypi --upgrade |
Since we already move ezpypi
to src
, we don’t have to worry about importing package from a local directory rather than Python site packages.
1 | python3 |
1 | import ezpypi |
Make a new branch
Since our current version is 0.2.x
, we should make a new branch maintenance/0.2.x
for this branch.
1 | git checkout -b maintenance/0.2.x |