From 93d78c300b94a34d25ea8c4b20aaf669039cffa3 Mon Sep 17 00:00:00 2001 From: Nick Coghlan Date: Thu, 24 May 2018 08:21:57 +1000 Subject: [PATCH] Reword cross-reference to the poetry project (#508) The key design distinction between pipenv and poetry isn't the overall scope of the projects, but rather the assumptions we make about how projects are going to be structured. pipenv focuses mainly on "git push" and "git archive" style publication, where there's a private distribution pipeline between the repo and production systems (e.g. this is really common in SaaS and embedded systems). poetry, by contrast, focuses on the case where a pyproject.toml file is already present, at which point having Pipfile as well (as `pipenv` requires if you want to use it to manage development and testing environments) may feel redundant. --- source/tutorials/managing-dependencies.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/source/tutorials/managing-dependencies.rst b/source/tutorials/managing-dependencies.rst index 47e1090c5..bf91dffd9 100644 --- a/source/tutorials/managing-dependencies.rst +++ b/source/tutorials/managing-dependencies.rst @@ -170,9 +170,9 @@ and techniques to see if one of them is a better fit: * `hatch `_ for opinionated coverage of even more steps in the project management workflow (such as incrementing versions, tagging releases, and creating new skeleton projects from project templates) -* `poetry `_ for Python developer focused - components that are designed primarily for publication to a Python package index - (``pipenv`` deliberately avoids making the assumption that the application - being worked on will support distribution as a ``pip``-installable Python package, - while ``poetry`` based applications rely explicitly on their Python packaging - metadata to describe their application structure and dependencies) +* `poetry `_ for a tool comparable in scope + to `pipenv` that focuses more directly on use cases where the repository being + managed is structured as a Python project with a valid ``pyproject.toml`` file + (by contrast, ``pipenv`` explicitly avoids making the assumption that the + application being worked on that's depending on components from PyPI will + itself support distribution as a ``pip``-installable Python package).