Python Feature


To use the Python Feature, make sure your Projectfile contains the following:

from medikit import require

python = require('python')

The python handle is a PythonConfig instance, and can be used to customize the feature.

The python features makes your package real (at least if it uses python). Medikit was written originally for python, and although it’s not completely true anymore, a lot of features depends on this.


You can define the setuptools’ setup(…) arguments using python.setup(…):

    description='Opinionated python 3.5+ project management.',
    license='Apache License, Version 2.0',
    author='Romain Dorgueil',
        'console_scripts': ['medikit=medikit.__main__:main'],

This is required for any python package.


Requirements are managed using two different mechanisms:

  • The file, autogenerated and overriden by medikit, will contain the “loose” requirements as you define them. You’re encouraged to use “~x.y.z” or “~x.y” versions. You should use each versions (“==x.y.z”) only in case you’re relying on a package you never want to update.
  • The requirements*.txt files will contain frozen version numbers. Those requirements will be commited, and you can ensure the reproducibility of your installs by using pip install -r requirements.txt instead of python install.

In medikit, we call what is present in “constraints”, and what is in requirements*.txt files “requirements”.

Let’s see how we can set them:

    "requests ~2.18"

This will set a constraint on any semver compatible requests version, and update the requirement to latest requests version, compatible with the constraint (as of writing, 2.18.4).

It means that if you run make install, python install or pip install -e ., requests will only be downloaded and installed if there is no installation complying to the constraint in your current env. This is very handy if you have local, editable packages that you want to use instead of PyPI versions.

It also means that when you run pip install -r requirements.txt, you’ll get requests 2.18.4 even if a new version was released.

If you want to upgrade to the new released version, use make update-requirements, review the git changes (git diff –cached), test your software with the new version and eventually (git) commit to this dependency update.


Sometimes, you want a dependency to only be a constraint, and not a frozen requirement.

    "certifi ~2018,<2019"

This will ensure that your env contains “certifi”, a version released in the 2018 year, but also says you don’t care which one.

This is an advanced feature that you should only use if you really know what you’re doing, otherwise, use a requirement (reproducibility of installs is gold).


You can create as much “extras” as you want.

As a default, medikit will create a “dev” extra, but you can add whatever you need:

        'sqlalchemy ~=1.2.5',

The same works with constraints, of course.

Changing package generation behaviour

Medikit creates the necessary directory structure for your package, named after your package name defined in the python.setup() call.

If you don’t want medikit to create this directory structure:

python.create_packages = False

Medikit also considers you’ll need a version number tracking mechanism for your project. It creates a file in your package’s root directory. To override this file’s name:

python.version_file = ''