Skip to content

Add PDM to the list of alternatives to Pipenv #1036

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 7 commits into from
Jan 23, 2022
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 21 additions & 20 deletions source/tutorials/managing-dependencies.rst
Original file line number Diff line number Diff line change
Expand Up @@ -21,10 +21,7 @@ applicable to the development and deployment of network services (including
web applications), but is also very well suited to managing development and
testing environments for any kind of project.

Developers of Python libraries, or of applications that support distribution
as Python libraries, should also consider the
`poetry <https://github.com/python-poetry/poetry>`_ project as an alternative dependency
management solution.
For alternatives, see `Other Tools for Application Dependency Management`_.

Installing Pipenv
-----------------
Expand Down Expand Up @@ -161,20 +158,24 @@ Other Tools for Application Dependency Management

If you find this particular approach to managing application dependencies isn't
working well for you or your use case, you may want to explore these other tools
and techniques to see if one of them is a better fit:

* `poetry <https://github.com/python-poetry/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).
and techniques, listed in alphabetical order, to see if one of them is a better fit:

* `hatch <https://github.com/ofek/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)
* `pip-tools <https://github.com/jazzband/pip-tools>`_ to build your own
custom workflow from lower level pieces like ``pip-compile`` and ``pip-sync``
* `micropipenv <https://github.com/thoth-station/micropipenv>`_ is a lightweight
wrapper for pip to support requirements.txt, Pipenv and Poetry lock files or
converting them to pip-tools compatible output. Designed for containerized
Python applications but not limited to them.
more steps in the project management workflow, such as incrementing versions,
tagging releases, and creating new skeleton projects from project templates.
* `micropipenv <https://github.com/thoth-station/micropipenv>`_ for a lightweight
wrapper around pip that supports ``requirements.txt``, Pipenv and Poetry lock files,
or converting them to pip-tools compatible output. Designed for containerized
Python applications, but not limited to them.
* `PDM <https://github.com/pdm-project/pdm>`_ for a modern Python package management
tool supporting :pep:`582` (replacing virtual environments with ``__pypackages__``
directory for package installation) and relying on standards such as :pep:`517` and
:pep:`621`.
* `pip-tools <https://github.com/jazzband/pip-tools>`_ for creating a lock file of all
dependencies from a list of packages directly used in a project, and ensuring that
only those dependencies are installed.
* `Poetry <https://github.com/python-poetry/poetry>`__ for a tool comparable in scope
to Pipenv that focuses more directly on use cases where the project being managed is
structured as a distributable Python package with a valid ``pyproject.toml`` file.
By contrast, Pipenv explicitly avoids making the assumption that the application
being worked on will support distribution as a ``pip``-installable Python package.