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, 4:01:40 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

9 sources
The underlying problem is the community's decision to make users manage this in the first place. This is an example of a setup.py that correctly installs the accelerated PyTorch for your platform: https://github.com/comfyanonymous/ComfyUI/blob/9aeaac4af5e19... As you can see, never merged. For philosophical reasons I believe. The author wanted to merge it earlier and changed his mind. Like why make end users deal with this at all? The ROI from a layperson choosing these details is very low. Python has a packaging problem, this is well known. Fixing setuptools would be highest yield. Other package tooling can't install PyTorch, for example: https://github.com/python-poetry/poetry/issues/6409#issuecom.... PyTorch itself is wonkily packaged. But I'm sure they have a good reason for this. Anyway, it goes to show that you can put a huge amount
Read the rest
of effort into fixing this particular problem that everyone touching this technology has, and the maintainers everywhere will go nowhere with it. And I don't think this is a "me" problem, because there is so much demand for packaging PyTorch correctly - all the easy UIs, etc.
In Use pytorch2+cu118 with ADA hardware for 50%+ speedup
It's not reasonable to expect the end user to figure out the correct toolchain triple URL there are so many os-driver-framework version combinations. https://download.pytorch.org/whl/torch/ It's meant to be an automated process, don't make excuses for poor implementation on behalf of Poetry. See for yourself the number of torch related issues: https://github.com/python-poetry/poetry/issues?q=is%3Aissue+... https://github.com/python-poetry/poetry/issues?q=is%3Aissue+... Not a week goes by without a new issue popping up. A dependency manager is a critical piece of infrastructure, it should not be the main developer experience bottleneck when building an application. A good package manager is out of sight, out of mind. You don't hear people complaining so much about Cargo every day.
In DeepFilterNet: Noise supression using deep filtering
I started using poetry for my OSS projects and I'm happy with it, but I'd never use it for closed source projects. Poetry simplifies deps, config, pkg build etc as it's stored in a single place, but it's way to opinionated. For managing dependencies only, pip tools is easier to use and customize. There's no breaking changes, it's a finished product. Also, I don't want my CI to fail randomly. https://github.com/python-poetry/poetry/pull/6297 Look at the number of issues in poetry. Some things are not backwards compat, some are broken. If you want reliable, KISS with pip tools. That's my opinion.
In Classifying Python virtual environment workflows

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.