HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
python-poetry
poetry
Python2018–2025
python-poetry / poetry

poetry

Python packaging and dependency management made easy

76Distinct people
93Mentions
1Explicit recommenders
34.3KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Python packaging and dependency management made easy

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

There's a bigger problem. Comes down to production issues and the efficiency of using something just because it's cool. I'm a grizzled setuptools guy, for sure. While I think…

b33j0r used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 2:17:07 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year93 dated mentions

Observed mentions: 2018-03-09 15:53:18 UTC to 2025-08-28 11:50:32 UTC.

051015202018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 19 mentions; 6 submissions, 13 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 18 mentions; 3 submissions, 15 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 17 mentions; 0 submissions, 17 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 12 mentions; 1 submissions, 11 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 9 mentions; 1 submissions, 8 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC19613
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC18315
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC808
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC17017
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC12111
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC918
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC707
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC303

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Poetry: Python packaging and dependency management made easy Poetry helps you declare, manage and install dependencies of Python projects, ensuring you have the right stack everywhere. Poetry replaces setup.py, requirements.txt, setup.cfg, MANIFEST.in and Pipfile with a simple pyproject.toml based project format. [build-system] requires = ["poetry-core>=2.0.0,<3.0.0"] build-backend = "poetry.core.masonry.api" [project] name = "my-package" version = "0.1.0" description = "The description of the package" readme = "README.md" license = "MIT" license-files = ["LICENSE"] # No Python upper bound for package metadata requires-python = ">=3.9" authors = [ { name = "Sébastien Eustace", email = "sebastien@eustace.io" }, ] # Keywords (translated to tags on the package index) keywords = ["packaging", "poetry"] dependencies = [ # equivalent to ^3.8.1 with semver constraints "aiohttp (>=3.8.1,<4.0.0)", # dependency with extras "requests[security] (>=2.28,<3.0)", # version-specific dependency with prereleases allowed (see below) "tomli (>=2.0.1,<3.0.0) ; python_version < '3.11'", # git dependency with branch specified "cleo @ git+https://github.com/python-poetry/cleo.git@main", ] [project.urls] repository = "https://github.com/python-poetry/poetry" homepage = "https://python-poetry.org" # Scripts are easily expressed [project.scripts] my_package_cli = "my_package.console:run" [project.optional-dependencies] # optional dependency to be installed via 'poetry install -E my-extra' my-extra = ["pendulum (>=3.1.0,<4.0.0)"] [tool.poetry.dependencies] # Python upper bound for locking python = ">=3.9,<4.0" # Version-specific dependencies with prereleases allowed tomli = { allow-prereleases = true } # Dependency groups are supported for organizing your dependencies [dependency-groups] dev = ["pytest (>=7.1.2,<8.0.0)", "pytest-cov (>=3.0,<4.0)"] docs = ["Sphinx (>=5.1.1,<6.0.0)"] # ...and can be installed only when explicitly requested # via 'poetry install --with docs' [tool.poetry.group.docs] optional = true # Alternatively, you can use Poetry specific syntax # to specify dependency groups [tool.poetry.group.lint] optional = true [tool.poetry.group.lint.dependencies] ruff = ">=0.10.0" Installation Poetry supports multiple installation methods, including a simple script found at install.python-poetry.org. For full installation instructions, including advanced usage of the script, alternate install methods, and CI best practices, see the full installation documentation. Documentation Documentation for the current version of Poetry (as well as the development branch and recently out of support versions) is available from the official website. Contribute Poetry is a large, complex project always in need of contributors. For those new to the project, a list of suggested issues to work on in Poetry and poetry-core is available. The full contributing documentation also provides helpful guidance. Resources Releases Official Website Documentation Issue Tracker Discord Related Projects poetry-core: PEP 517 build-system for Poetry projects, and dependency-free core functionality of the Poetry frontend poetry-plugin-export: Export Poetry projects/lock files to foreign formats like requirements.txt poetry-plugin-bundle: Install Poetry projects/lock files to external formats like virtual environments install.python-poetry.org: The official Poetry installation script website: The official Poetry website and blog Supporters Thanks to JetBrains for supporting us with licenses for their tools.
Read the full README on GitHub

What Hacker News says

18 sources
hopefully v1.0 now means it's pretty stable. using poetry so far has been painful, the gains you got with the improved dependency resolution were unfortunately somewhat impacted by crazy annoying bugs, like `poetry shell` not actually activating the virtual environment [0] [0] https://github.com/python-poetry/poetry/issues/571 edit: gah, still hitting baffling errors: $ poetry env use /usr/local/bin/python3 [NoCompatiblePythonVersionFound] The specified Python version (3.7) is not supported by the project (^3.7). Please choose a compatible version or loosen the python constraint specified in the pyproject.toml file. $ poetry env use /usr/local/bin/python3 [NoCompatiblePythonVersionFound] The specified Python version (3.7) is not supported by the project (>=3.7). Please choose a compatible version or loosen the python c
Read the rest
onstraint specified in the pyproject.toml file. v1.0.0 generally seems to work smoother though
In Poetry – Dependency Management for Python – v1.0
For whatever reason, I've never understood the point or actual benefit of virtualenvs. Having lived more in the JS ecosystem for the last several years, my ideal workflow would be a copy of how the Yarn package manager works: - Top-level dependencies defined in an editable metadata file - Transitive dependencies with hashes generated based on the calculated dependency tree - All dependencies installed locally to the project, in the equivalent of a `node_modules` folder - All package tarballs / wheels / etc cached locally and committed in an "offline mirror" folder for easy and consistent installation - Attempting to reinstall packages when they already are installed in that folder should be an almost instantaneous no-op PEP-582 (adding standard handling for a "__pypackages__" folder) appears to be the equivalent of `node_modules` that I'v
Read the rest
e wanted, but tools don't seem to support it yet. I'd looked through several Python packaging tools over the last year, but none of them seemed to support it yet (including Poetry [0]). The only tool that I can find that really supports PEP-582 atm is `pythonloc` [1], which is really just a wrapper around `python` and pip` that adds that folder to the path. Using that and `pip-tools`, I was able to mostly cobble together a workflow that mimics the one I want. I wrote a `requirements.in` file with my main deps, generated a `requirements.txt` with the pinned versions and hashes with `pip-compile`, was able to download and cache them using `pip`, and installed them locally with `piploc`. Admittedly, I've only tried this out once a few weeks ago on an experimental task, but it seemed to work out sufficiently, and I intend to implement that workflow on several of our Python services in the near future. If anyone's got suggestions on better / alternate approaches, I'd be interested. [0] https://github.com/python-poetry/poetry/issues/872 [1] https://github.com/cs01/pythonloc [2] https://github.com/jazzband/pip-tools
In Poetry – Dependency Management for Python – v1.0
> The 2/3 mess (yes it is still a thing) It's still a thing for the (loud) few who couldn't manage to move to 3 after 10 years. The rest just went on. The ecosystem is on 3 [0] and it has been for years now. [0]: http://py3readiness.org/ > The insane packaging situation. Packaging a Python app is a nightmare. The packaging story in Python is in the middle of a big transformation from legacy tools to modern npm/yarn/cargo-like tools. pipenv [1] and poetry [2] are the most popular contenders. It will take a while until the community settles on this, but both tools work already. [1]: https://github.com/pypa/pipenv [2]: https://github.com/sdispater/poetry > Dynamically typed Python 3.5 introduced type annotations. It is now possible to write statically typed code in Python via mypy [3], which from my experience works similar well as TypeScrip
Read the rest
t works for JavaScript. [3]: https://github.com/python/mypy
In My 2019 programming language hierarchy
There are two new tools in the Python ecosystem, which try to fill the gap left by cargo, npm, yarn & co.: One is pipenv [0], which works similar to yarn & co. It uses Pipfile/Pipfile.lock to define and lock dependencies. Pipenv has a major flaw: It can't be used to publish packages on pypi.org (you still need twine & setup.py for that). It's also known for being slow and somewhat buggy. Despite all that pipenv is an "official" tool maintained by the "Python Packaging Authority". The other one is poetry [1], which works exactly like yarn & co. It uses "pyproject.toml" to specify dependencies and "poetry.lock" to lock them. Poetry does most of the things "right", but it's still an underdog compared to pipenv. Both tools have not yet fully matured, thus there are a lot of complaints. [0]: https://github.com/pypa/pipenv [1]: https://github.c
Read the rest
In My Python Development Environment, 2020 Edition
You can write Python like pseudo-code. Sometimes the results look almost like plain English. For example, if I have to design software for a micro-controller that uses C/C++ I sometimes write down the algorithm in Python (with editor support: auto-formatting, etc.), then I implement it in C/C++. There is no better way to write pseudo-code that I know of. Python is also great to create a prove of concept for something. It allows for rapid prototyping due to the simple syntax, the high-level features, the huge ecosystem and the dynamic type system. Most of the time the result is good enough for production. You can add type annotations and get statically typing via mypy [0] to harden the code base. This works really well. (See: JS->TypeScript). Python has a well developed FFI which allows you to call C/C++/Rust, without large performance hit
Read the rest
s. I think this is one of the main reasons for Python's success. It can be used as a high level interface to a huge low level ecosystem. ML wouldn't exist in Python without that. Python is a great language to create simple scripts as well. I use it as a bash replacement. But beware: Python can get really ugly if you rely too heavily on OOP/Inheritance. There is a lot of ugly Python code out there. I think Python shines the most if you use it in a procedural/semi-functional style and describe data-types for your business logic (almost) entirely with (dump) dataclasses [1] and namedtuples [2]. Beware2: Python's packaging story (package manager, etc) is currently in a messy state. There are good solutions, but it's difficult to find the right tools for a newcomer. I think it will take a couple of years for the dust to clear, but you might want to check out pipenv [7] or poetry [8] These packages will make your life a lot easier. I use them for every project: - black [3] or yapf [4] (auto-formatter) - mypy [0] (statically typing with editor support for VSCode) - pylint [5] or flake8 [6] (linter) [0] https://github.com/python/mypy [1] https://docs.python.org/3/library/dataclasses.html#module-da... [2] https://docs.python.org/3/library/typing.html#typing.NamedTu... [3] https://github.com/psf/black [4] https://github.com/google/yapf [5] https://github.com/PyCQA/pylint/ [6] https://github.com/PyCQA/flake8 [7] https://github.com/pypa/pipenv [8] https://github.com/sdispater/poetry
In Python Is Eating the World
That's funny, Poetry's README [1] claims exactly the opposite (that it resolves dependencies better than pipenv). And looking at the git history, that section of the README is 2 years old, so that claim was made when you experimented. Was the problem with dependency resolution you had similar to what Poetry describes in it README? Or are there other problems the README fails to mention? The description they make got me interested, but up to now all alternatives I tried to build moderately complex python projects failed to deliver on their promises, so definitely interested in what you have to say. [1] https://github.com/sdispater/poetry/blob/master/README.md#de...
In Poetry: Dependency Management for Python

Showing the 15 most recent of 18 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.