This version brings a new shell command, dependency resolver improvements and improves stability.

New Features

New shell command

The newly introduced shell command helps you in your development workflow by placing you in the proper project environment. This way you can omit the poetry run command.

Note that this command is a usability improvement and, as such, is completely optional and any current workflow using the poetry run command will still work and is still the recommended way of interacting with a Poetry project.

The shell command tries its best to detect your current shell but sometimes will stil fail. In this case, you can use poetry run <your-shell> to get the same behavior.

packages property

When you project does not follow the standard project structure supported by Poetry and your packages lie somewhere else, you can use the packages property under the tool.poetry section.

[tool.poetry] # ... packages = [ { include = "mypackage" } , { include = "extra_package/**/*.py" } , ]

If your package is stored inside a "source" directory, you must specify it:

[tool.poetry] # ... packages = [ { include = "mypackage" , from = "lib" } , ]

Using packages disables the package auto-detection feature meaning you have to explicitly specify the "default" package.

Poetry is clever enough to detect Python subpackages. So, you only have to specify the directory where you root package resides.

include and exclude properties

You can explicitly specify to Poetry that a set of globs should be ignored or included for the purposes of packaging. The globs specified in the exclude field identify a set of files that are not included when a package is built.

[tool.poetry] # ... include = [ "CHANGELOG.md" ] exclude = [ "my_package/excluded.py" ]

Changes

Dependency resolver improvements

Support for different version constraints for a same dependency

If a package the main project depends on has different version constraints for a same package due to different system requirements (like the Python version), Poetry will now properly resolve all branches caused by this.

Let's take an example: docker . docker depends on two versions of pypiwin32 :

pypiwin32 (==219); sys_platform == "win32" and python_version < "3.6" pypiwin32 (==220); sys_platform == "win32" and python_version >= "3.6"

So, if the main project supports Python < 3.6 and >= 3.6, poetry needs to lock both.

The resolver is now clever enough to resolve for both branches created by the docker package, which in turn makes it no longer raise an error about a conflict which does not exist.

Dependency installation order

When installing resolved dependencies, Poetry will now install the deepest dependencies first. This solves issues when a package needs one of its dependency at installation time.

Better error messages

Error messages from the resolver are now better at explaining what happened.

For instance, if a conflict has been caused by incompatible Python versions the error message will display the current Python version to provide more context:

[SolverProblemError] The current supported Python versions are ~2.7 Because my-package depends on django (2.0.6) which requires Python >=3.4, version solving f ailed.

Other changes

poetry now always reads/writes the pyproject.toml file with the utf-8 encoding.

now always reads/writes the file with the encoding. config --list now lists all available settings.

now lists all available settings. init no longer adds pytest to development dependencies.

Fixes