If you are developing in an open source project, it's good practice to publish your project to the PyPI at https://pypi.python.org/pypi.

Like most modern language ecosystem, this index can be browsed by installers that are looking for releases to download.

When you call the pip install <project> command, PIP will browse the PyPI index to see if that project exists, and if there are some suitable releases for your platform.

The public name is the name you use in your setup.py file and you need to register it at PyPI in order to be able to publish some releases. The index uses the first-come, first-serve principle, so if the name you've picked is taken, you will have to choose another one.

When creating microservices for an application or an organization, you can use a common prefix for all your projects' names. For Runnerly, runnerly- is used.

At the package level, a prefix can also sometimes be useful to avoid conflicts.

Python has a namespace package feature, which allows you to create a top-level package name (like runnerly), and then have packages in separate Python projects, which will end up being installed under the top-level runnerly package.

The effect is that every package gets a common runnerly namespace when you import them, which is quite an elegant way to group your code under the same banner. The feature is available through the pkgutil module from the standard library.

To do this, you just need to create the same top-level directory in every project, with the __init__.py file containing and prefixing all absolute imports with the top-level name.

from pkgutil import extend_path 
__path__ = extend_path(__path__, __name__) 

For example, in Runnerly, if we decide to release everything under the same namespace, each project can have the same top-level package name. For example, in the token dealer, it could be as follows:

• runnerly
  • __init__.py: Contains the extend_path call
  • tokendealer/
    • .. the actual code...

And then in the dataservice one, like this:

• runnerly
  • __init__.py: Contains the extend_path call
  • dataservice/
    • .. the actual code...

Both will ship a runnerly top-level package, and when PIP installs them, the tokendealer and dataservice packages will both end up in the same directory, site-packages/runnerly.

This feature is not that useful in production, where each microservice is deployed in a separate installation, but it does not hurt and is good to have, as it can be useful if you start to create a lot of libraries that are used across projects.

For now, we'll make the assumption that each project is independent, and each name is available at PyPI.

To publish the releases at PyPI, you first need to register a new user using the form at https://pypi.python.org/pypi?%3Aaction=register_form, shown as follows:

Once you have a username and a password, you should create, in your home directory, a .pypirc file containing your credentials, like this:

[pypi] 
username = <username> 
password = <password> 

This file will be used every time you interact with the PyPI index to create a Basic Authentication header.

Python Distutils has a register and upload command to register a new project at PyPI, but it is better to use Twine (https://github.com/pypa/twine), which comes with a slightly better user interface.

Once you've installed Twine (using the pip install twine command), the next step is to register your package with this command:

$ twine register dist/runnerly-tokendealer-0.1.0.tar.gz 

The preceding command will create a new entry in the index using your package metadata.

Once it's done, you can go ahead and upload the releases as follows:

$ twine upload dist/* 

From there, your package should appear in the index, with an HTML home page at https://pypi.python.org/pypi/<project>. And the pip install <project> command should work!

Now that we know how to package each microservice, let's see how to run them all in the same box for development purposes.