dephell 0.5.8

Dependency resolution for Python

DepHell – project management for Python.

Why it is better than all other tools:

1. Format agnostic. You can use DepHell with your favorite format: setup.py, requirements.txt, Pipfile, poetry. DepHell supports them all and much more.

2. Use your favorite tool on any project. Want to install a poetry based project, but don’t like poetry? Just say DepHell to convert project meta information into setup.py and install it with pip. Or directly work with the project from DepHell, because DepHell can do everything what you usually want to do with packages.

3. DepHell doesn’t try to replace your favorite tools. If you use poetry, you have to use poetry’s file formats and commands. However, DepHell can be combined with any other tool or even combine all these tools together through formats converting. You can use DepHell, poetry and pip at the same time.

4. Easily extendable. Pipfile should be just another one supported format for pip. However, pip is really old and big project with many bad decisions, so, PyPA team can’t just add new features in pip without fear to broke everything. This is how pipenv has been created, but pipenv has inherited almost all problems of pip and isn’t extendable too. DepHell has strong modularity and can be easily extended by new formats and commands.

5. Developers friendly. We aren’t going to place all our modules into ``_internal` <https://github.com/pypa/pip/tree/master/src/pip/_internal>`_. Also, DepHell has big ecosystem with separated libraries to help you use some DepHell’s parts without pain and big dependencies for your project.

6. All-in-one-solution. DepHell can manage dependencies, virtual environments, tests, CLI tools, packages, generate configs, show licenses for dependencies, make security audit, get downloads statistic from pypi, search packages and much more. None of your tools can do it all.

7. Smart dependency resolution. Sometimes pip and pipenv can’t lock your dependencies. Try to execute pipenv install oslo.utils==1.4.0. Pipenv can’t handle it, but DepHell can: dephell deps add --from=Pipfile oslo.utils==1.4.0 to add new dependency and dephell deps convert --from=Pipfile --to=Pipfile.lock to lock it.

8. Asyncio based. DepHell doesn’t support Python 2.7, and that allows us to use modern features to make network and filesystem requests as fast as possible.

9. Multiple environments. You can have as many environments for project as you want. Separate sphinx dependencies from your main and dev environment. Other tools like pipenv and poetry don’t support it.

Features:

• Manage dependencies: convert between formats, instаll, lock, add new, resolve conflicts.

• Manage virtual environments: create, remove, inspect, run shell, run commands inside.

• Install CLI tools into isolated environments.

• Manage packages: install, list, search on PyPI.

• Build packages (to upload on PyPI), test, bump project version.

• Discover licenses of all project dependencies, show outdated packages, find security issues.

• Generate .editorconfig, LICENSE, AUTHORS, .travis.yml.

See documentation for more details.

Installation

The simplest way:

python3 -m pip install --user dephell[full]

See installation documentation for better ways.

Supported formats

1. Archives:

   1. *.egg-info (egginfo)

   2. *.tar.gz (sdist)

   3. *.whl (wheel)

2. pip:

   1. requirements.txt (pip)

   2. requirements.lock (piplock)

3. pipenv:

   1. Pipfile (pipfile)

   2. Pipfile.lock (pipfilelock)

4. pоetry:

   1. pyproject.toml (poetry)

   2. poetry.lock (poetrylock)

5. Other:

   1. setup.py (setuppy)

   2. pyproject.toml build-system requires (pyproject)

   3. Installed packages (installed).

Usage

First of all, install DepHell and activate autocomplete:

python3 -m pip install --user dephell[full]
dephell autocomplete

Let’s get sampleproject and make it better.

git clone https://github.com/pypa/sampleproject.git
cd sampleproject

This project uses setup.py for dependenciesand metainfo. However, this format over-complicated for most of projects. Let’s convert it into poetry:

dephell deps convert --from=setup.py --to=pyproject.toml

It will make next pyproject.toml:

[tool.poetry]
name = "sampleproject"
version = "1.2.0"
description = "A sample Python project"
authors = ["The Python Packaging Authority <[e-mail]>"]
readme = "README.md"

[tool.poetry.scripts]
sample = "sample:main"

[tool.poetry.dependencies]
python = "!=3.0.*,!=3.1.*,!=3.2.*,!=3.3.*,<4,>=2.7"
coverage = {optional = true}
peppercorn = "*"

[tool.poetry.dev-dependencies]
check-manifest = "*"

[tool.poetry.extras]
test = ["coverage"]

Now, let’s generate some useful files:

dephell generate authors

dephell generate license MIT

# https://editorconfig.org/
dephell generate editorconfig

Our users, probably, has no installed poetry, but they, definitely, has pip that can install files from setup.py. Let’s make it easier to generate setup.py from our pyproject.toml. Also, it points for DepHell your default dependencies file. Add next lines in the pyproject.toml:

[tool.dephell.main]
from = {format = "poetry", path = "pyproject.toml"}
to = {format = "setuppy", path = "setup.py"}

You can see full real world example of config in DepHell’s own pyproject.toml.

Now we can call DepHell commands without explicitly specifying from and to:

dephell deps convert

It will make setup.py and README.rst from pyproject.toml and README.md.

Now let’s test our code into virtual environment:

$ dephell venv run pytest
WARNING venv does not exist, creating... (project=/home/gram/Documents/sampleproject, env=main, path=/home/gram/.local/share/dephell/venvs/sampleproject-Whg0/main)
INFO venv created (path=/home/gram/.local/share/dephell/venvs/sampleproject-Whg0/main)
WARNING executable does not found in venv, trying to install... (executable=pytest)
INFO build dependencies graph...
INFO installation...
# ... pip output
# ... pytest output

Also, we can just activate virtual environment for project and run any commands inside:

dephell venv shell

Ugh, we have tests, but have no pytest in our dependencies file. Let’s add it:

dephell deps add --envs dev test -- pytest

Afer that our dev-dependencies looks like this:

[tool.poetry.dev-dependencies]
check-manifest = "*"
pytest = "*"

[tool.poetry.extras]
test = ["coverage", "pytest"]

One day we will have really many dependencies. Let’s have a look how many of them we have now:

$ dephell deps tree
- check-manifest [required: *, locked: 0.37, latest: 0.37]
- coverage [required: *, locked: 4.5.3, latest: 4.5.3]
- peppercorn [required: *, locked: 0.6, latest: 0.6]
- pytest [required: *, locked: 4.4.0, latest: 4.4.0]
  - atomicwrites [required: >=1.0, locked: 1.3.0, latest: 1.3.0]
  - attrs [required: >=17.4.0, locked: 19.1.0, latest: 19.1.0]
  - colorama [required: *, locked: 0.4.1, latest: 0.4.1]
  - funcsigs [required: >=1.0, locked: 1.0.2, latest: 1.0.2]
  - more-itertools [required: <6.0.0,>=4.0.0, locked: 5.0.0, latest: 7.0.0]
    - six [required: <2.0.0,>=1.0.0, locked: 1.12.0, latest: 1.12.0]
  - more-itertools [required: >=4.0.0, locked: 7.0.0, latest: 7.0.0]
  - pathlib2 [required: >=2.2.0, locked: 2.3.3, latest: 2.3.3]
    - scandir [required: *, locked: 1.10.0, latest: 1.10.0]
    - six [required: *, locked: 1.12.0, latest: 1.12.0]
  - pluggy [required: >=0.9, locked: 0.9.0, latest: 0.9.0]
  - py [required: >=1.5.0, locked: 1.8.0, latest: 1.8.0]
  - setuptools [required: *, locked: 41.0.0, latest: 41.0.0]
  - six [required: >=1.10.0, locked: 1.12.0, latest: 1.12.0]

Hm… Is it many or not? Let’s look on their size.

$ dephell inspect venv --filter=lib_size
11.96Mb

Ugh… Ok, it’s Python. Are they actual?

$ dephell deps outdated
[
  {
    "description": "More routines for operating on iterables, beyond itertools",
    "installed": [
      "5.0.0"
    ],
    "latest": "7.0.0",
    "name": "more-itertools",
    "updated": "2019-03-28"
  },
]

Pytest requires old version of more-itertools. That happens.

If our tests and dependencies are OK, it’s time to deploy. First of all, increment project version:

$ dephell project bump minor
INFO generated new version (old=1.2.0, new=1.3.0)

And then build packages:

$ dephell project build
INFO dumping... (format=setuppy)
INFO dumping... (format=egginfo)
INFO dumping... (format=sdist)
INFO dumping... (format=wheel)
INFO builded

Now, we can upload these packages on PyPI with twine.

This is some of the most useful commands. See documentation for more details.

Compatibility

DepHell tested on Linux and Mac OS X with Python 3.5, 3.6, 3.7. And one of the coolest things that DepHell ran by DepHell on Travis CI.

How can I help

1. Star project on Github. Developers believe in the stars.

2. Tell your fellows that Gram has made cool thing for you.

3. Open an issue if you have thoughts how to make DepHell better.

4. Things that you can contribute in any project in DepHell ecosystem:

   1. Fix grammar and typos.

   2. Document new things.

   3. Tests, we always need more tests.

   4. Make READMEs more nice and friendly.

   5. See issues by help wanted label to find things that you can fix.

   6. Anything what you want. If it is a new feature, please, open an issue before writing code.

Thank you :heart: