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, 3:30:57 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

17 sources
False. Poetry implements it’s own dependency resolver. It does not use pip’s resolver. For most packages this is fine. For a couple packages it’s resolver does not work. Pytorch is one major ml library that is incompatible with poetry as poetry has a non-standard interpretation of local package version tags. https://github.com/python-poetry/poetry/issues/4231 Is one issue. If you even transitively depend on pytorch poetry will break and you will need hacks to make it work or just give up.
In Show HN: Jupyter kernel using Poetry for reproducible Python package management
I can't recommend using Poetry in production - I've had massive headaches with it due to https://github.com/python-poetry/poetry/issues/697 Basically if you have two dependencies that depend on the same package, but depend on different versions or non-overlapping ranges of versions, Poetry's only solution is "tell the maintainers of your dependencies to update their pyproject.toml" - building your package will just fail, with no workaround other than to fork the dependencies and update pyproject.toml yourself. Yes, in principle that sounds like the right way to resolve it, but in practice there are lots of Python packages with overly narrow dependency version ranges (or that are pinned to a single version), the maintainers understandably aren't always that responsive, and forking all your dependencies isn't a great solution.
In Django 4.0
Tangent: Poetry can have very slow dependency resolution. It doesn't cut to the core of the problem: Pypi doesn't enforce clearly specifying dependencies. Many packages do, like in Wheels metadata, but Poetry ignores this, and installs each package. There are some ways around it. For example, build an independent cache of metadata to use instead of Pypi directly. For discussion on the topic, see this GH issue: https://github.com/python-poetry/poetry/issues/2094#issuecom... This is now fixed, but for most of Poetry's life, it took some tricks to work on Python 3, at least on Windows; the workaround wasn't documented. So, it'd always assume Python 2. I can't remember the details, but tried and quit Poetry several times during its early life for this reason.
In Ask HN: Why Poetry did not become a mainstream package manager for Python?
b33j0r·Jun 19, 2021Recommendation phrase
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 poetry has many great ideas, it currently can't be used in a container-based microservices ecosystem with even one problematic dependency (without monkeypatching or forking crazy things like `requests` in some cases). Proprietary dependencies make it even more painful, but that can be fixed. My current organization had adopted poetry before I arrived, and I eventually had to decide that we're reversing from poetry, back to pip and explicit usage of setuptools. It was too problematic, and was costing us in production DLL-hell bugs. The solver does not allow you to pin a constraint if it conflicts with the packaging metadata of your dependencies. The stance of the poet
Read the rest
ry team is that any discrepancies should be fixed in upstream dependency. Hey, I love purity and platonic solids too, but... so that's not a completely crazy design decision, but we're in an NP problem here. That stance requires the cooperation of every single upstream package maintainer, which obviously, no one can actually operationalize. Here is a very old issue about this: https://github.com/python-poetry/poetry/issues/697#issuecomm... There is some movement, and acknowledgment that a tool is useless if you can't take it full-stack for your application. As of writing, the state of the art is to fork and patch things like fastapi and flask. That's nuts. I can make our stack work with the tested tools much more consistently, and there isn't much downside. https://github.com/python-poetry/poetry/issues/697#issuecomm... To me, that removes the value of using poetry. `poetry install <x>` is something you do very rarely. Propping up new python environments needs to happen very frequently. The convenience doesn't outweigh the operational costs. tl;dr: I think poetry is really cool, and it looks like npm to a developer. It doesn't play nice with others, and that's by design. For production use, pip/setuptools solves more problems than people think it does. Sure, constraints.txt is a blunderbuss for a dependency resolver. However, it works. Especially if you are making more than one package for a real-world application. If you are maintaining a standalone library without complex dependencies, sure, go for it :)
In Ask HN: Why Poetry did not become a mainstream package manager for Python?
Poetry does need help. I created a thread here: https://github.com/python-poetry/poetry/issues/4160 my primary concern poetry's development stagnating due to natural causes while many projects rely on it. switching costs are high. moving from pipenv -> poetry took me days across all my projects. they're looking for developers, but also help with managing issues on the tracker. i also raised the issue of them being funded. I think one possible outcome is seeing if PSF's Fiscal Sponsoree program (https://www.python.org/psf/fiscal-sponsorees/) would be a fit. Waiting to see what their maintainers say.
In Ask HN: Why Poetry did not become a mainstream package manager for Python?
Future-proof... Poetry 1.1 broke compatibility with 1.0. 1.1 lockfiles would crash Poetry 1.0, and 1.0 lockfiles would be thrown away by Poetry 1.1. It does not correctly verify hashes (if at all) [1]. You can't add packages without updating all your dependencies. Monorepos are not supported. PEP-508-compliant Git dependencies cause the tool to crash with TypeError [2]. I think Poetry is the right direction, I use it for everything, but it's not the silver bullet you're painting it to be (yet). It's definitely not on par with Cargo, or maybe even npm. [1]: https://github.com/python-poetry/poetry/issues/3765 [2]: https://github.com/python-poetry/poetry/issues/3425
In How to make a Python package in 2021
The most frustrating thing is that pip doesn't make it easy to use more loose declared dependencies while freezing to actual concrete dependencies for deployment. Everybody rolls their own. > Python libraries should not pin dependencies. _Applications_ can pin dependencies, including all recursive dependencies of their libraries. Is the pypi package awscli an application or a library? poetry is frustrating in that it doesn't allow you to override a library's declared requirements to break conflicts. They refuse to add support [1][2] for the feature too. awscli for example causes huge package conflict issues that make poetry unusable. It's almost impossible not to run into a requirement conflict with awscli if you're using a broad set of packages, even though awscli will operate happily with a more broad set of requirements than it declare
Read the rest
In The modern packager’s security nightmare
When a cert is specified for a repo, the solver will use the cert and ca list when querying for packages, but after solving won't pass the cert and verify values when constructing the requests session to download the packages. There's a fix in https://github.com/python-poetry/poetry/pull/3490, but it has been pending review for several months. There's a second issue (this one isn't cert related) where repos that return a 403 when a given package doesn't exist causes the solver to abort, which is problematic if your private repo is Artifactory, since the solver interprets this as an auth misconfiguration and won't fall back to the primary repo. Based on some comments in the threads for those PRs I wondered if maybe the delay in merging was that some changes to the way repositories are configured, but it'd be great to have a temporary worka
Read the rest
round for the time being.
In A Poetic Apology: Or Why Should You Use Poetry to Manage Python Dependencies
Poetry (and now pip with its new resolver) has taken a hard line on not letting you install conflicting dependencies(1)(2). On the surface this sounds ideal: you can't wind up with some combination of packages that won't work together. The reality is that there are tons of Python libraries out there with poorly specified (or just slightly out of date) dependencies, and it's super annoying to have your package manager just give up and say "sorry, not installing that!" when you encounter them. This is an issue when working on applications with lots of dependencies, where I know certain packages will work together despite their setup.py files claiming otherwise. There are many reasons you'd want to install a version of a library that disagrees with one of your other dependencies...security updates in subdependencies, maintainers who are slow
Read the rest
to test against new versions or don't even use their own libraries anymore etc. The answer in these cases shouldn't be limited to "work with the package maintainer to get the dependencies changed, or fork it". Yarn, for example, has a simple way to handle this situation (and a clear understanding of why it's necessary baked into the docs!) (3) [1] https://github.com/python-poetry/poetry/issues/697 [2] https://github.com/pypa/pip/issues/8076 [3] https://classic.yarnpkg.com/en/docs/selective-version-resolu...
In A Poetic Apology: Or Why Should You Use Poetry to Manage Python Dependencies
> This while we have elephants in the room such as packaging. Researching best practices to move away from setup.py right now takes you down a rabbit hole of (excellent) blog posts, and yet you still need a setup.py shim to use editable installs, because the new model simply doesn't yet support this fundamental feature. You can do editable installs with poetry, I do it every day. Just run this: \rm -rv dist/; poetry build --format sdist && tar --wildcards -xvf dist/.tar.gz -O '/setup.py' > setup.py && pip3 install --prefix="${HOME}/.local/" --editable . More details here: https://github.com/python-poetry/poetry/issues/34#issuecomme...
In Pattern matching accepted for Python

Showing the 15 most recent of 17 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.