pypa

packaging-problems

Developer Tools2018–2026

pypa / packaging-problems

packaging-problems

An issue tracker for the problems in packaging

Developer Tools

Explore on GitHub Read Hacker News discussions

9Distinct people

9Mentions

0Explicit recommenders

192GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

An issue tracker for the problems in packaging

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

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

Also in these discussions

pypa/manylinux · linked in 2 of the same discussions

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

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM 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 year9 dated mentions

Observed mentions: 2018-10-12 21:48:24 UTC to 2026-09-08 00:48:52 UTC.

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

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.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	2	2
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	1	1
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	3	3
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	1	1
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	0	0
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	0	0
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	0	0
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	1	1
2026 (partial)	2026-01-01 00:00:00 UTC	2027-01-01 00:00:00 UTC	1	1

What Hacker News says

9 sources

zbentley·Sep 8, 2026

Declare the optional dependency and then import it unconditionally if the optional is installed. You can conditionally import a file you control based on asking whether an optional specifier was installed, either by probing the filesystem, a CLI argument, an environment variable, or whatever folks come up with for https://github.com/pypa/packaging-problems/issues/215. The "if: ... import" laziness-defeating clause only applies to your stub module, and the imports in that module are unconditional and thus will work with analyzers/laziness/etc. If you need something for one-off scripts, use https://docs.astral.sh/uv/guides/scripts/.

In Working to Make Python Lazy

zahlman·Aug 1, 2025

> avoiding chicken-and-egg problems by writing the tool for managing a programming language environment in a different language I've heard this a lot, but I don't really understand the use case. It seems that people want to do development in Python, want to install and manage third-party Python packages, and know how to use command-line tools, but somehow they don't already have Python installed and would find it challenging to install directly? Building from source on Linux is a standard "get dev packages from the system package manager; configure, make and install" procedure that I've done many times (yes, putting it beside the system Python could break things, but you can trivially set an alternate install prefix, and anyway the system Python will usually be a version that meets the basic needs of most developers). Installing on Window

Read the rest

s is a standard Windows installer experience. Aside from that, people seem to imagine "chicken-and-egg" scenarios with pip making itself available in the environment. But this is a thoroughly (if inefficiently) solved problem. First off, for almost three years now pip has been able to install cross-environment (albeit with an ugly hack; I detail some of this in https://zahlman.github.io/posts/2025/01/07/python-packaging-...). Second, the standard library `venv` defaults to bootstrapping pip into new environments — taking advantage of the fact that pre-built Python packages are zip archives, and that Python has a protocol for running code from zip archives, which the pip package implements. The real bootstrapping issue I've heard about is https://github.com/pypa/packaging-problems/issues/342 , but this affects very few people — basically, Linux distro maintainers who want to "build" an entire Python toolchain "from source" even though it's all Python code that the runtime could bytecode-compile on demand anyway.

In Programmers aren’t so humble anymore, maybe because nobody codes in Perl

BerislavLopac·Feb 17, 2021

You are right, building native extensions seems to have been left behind with the whole move to configuration-based builds (using pyproject.toml, as opposed to the "script-based" builds, using setup.py). That said, the configuration format itself is supposed to be universal -- but apparently none of the current tools support building extensions. That means that you are stuck with distutils, which should be available as part of setuptools -- PEP632 offers some migration advice [0]. I'd also recommend asking for advice on the packaging discussion board [1]. EDIT: And there is also the PyPA's official packaging problems tracker, FWIW [2]. [0] https://www.python.org/dev/peps/pep-0632/#migration-advice [1] https://discuss.python.org/c/packaging/14 [2] https://github.com/pypa/packaging-problems

In What’s New in Python 3.10

cozzyd·Sep 30, 2020

Yes... that's exactly what I was referring to. The problem is this: https://github.com/pypa/packaging-problems/issues/328

In Python 3.9 is around the corner

Caligatio·Aug 8, 2020

You can really go down the rabbit hole trying to figure out where the wheel+Alpine problem should be fixed. https://github.com/pypa/packaging-problems/issues/69 is a newer bug that is tracking this. Python relies on the "manylinux" specification (https://github.com/pypa/manylinux) which originally pinned build environments to CentOS 5, was updated in 2018 to use CentOS 6, and then updated in 2019 to use CentOS 7. It's entirely possible that the Alpine user base isn't as big/important as I would think but this seems like something that needs to be solved.

In Poetry – Python dependency management and packaging

masklinn·Jan 29, 2020

> If you just need pandas, then you can install it with apk along with many other packages and it'll be much quicker: https://pkgs.alpinelinux.org/packages?page=1&branch=edge&nam.... And so again need to rely on something "non-standard". > Alpine are doing what they can, by maintaining common python packages on apk. It is pip that is tied to glibc The "manylinux" tag means glibc by necessity, because nobody has driven a PEP for tagging, detecting and managing musl-based wheels to completion[0]. The issue is not restricted to the choice of libc, or even linux alone, either. But again, that requires people actually put in the work to chip at and fix the issue[1]. [0] https://github.com/pypa/manylinux/issues/37 [1] https://github.com/pypa/packaging-problems/issues/69

In Alpine makes Python Docker builds slower, and images larger

theamk·Nov 9, 2019

Many package managers provide a real audit trail, and this (IMHO) is very valuable. For example, in python's PIP (and apparently in NPM too), the filenames are never reused: https://github.com/pypa/packaging-problems/issues/74 Developer's website may change at any time, and even go back-and-forth between good and bad version. The pip software version won't. Put a version pin, and you can be sure you get a good package or an clear error. Granted, you can record/verify the checksum of downloaded files as well, but many people don't. And crazy practices like 'curl | sh' make that impossible anyway.

In Curl to shell isn't so bad

di·Oct 18, 2018

> Why not bundle twine like pip? The `pip` package is not actually bundled with your Python distribution, instead the standard library has `ensurepip` which provides a means of bootstrapping a `pip` installation without `pip` itself. See [0]. > In fact, why not merge the twine functionality into pip? This has been considered and still might happen, see [1], specifically the comment at [2]. [0] https://docs.python.org/3/library/ensurepip.html [1] https://github.com/pypa/packaging-problems/issues/60 [2] https://github.com/pypa/packaging-problems/issues/60#issueco...

In Python's New Package Landscape

martey·Oct 12, 2018

Incremental brownouts only work well if there is mechanisms to ensure that your service's users realize that the brownout is a deprecation warning. By default, pip doesn't show the contents of HTTP error messages [1], so users affected by the brownout would have to take extra steps (using `-v`, visiting the PyPI status page) in order to figure out what was wrong. I think it could easily appear as a networking issue or some other sort of intermittent problem. There was also no notification of the impending blackout on python.org. [2] [1]: https://github.com/pypa/packaging-problems/issues/130 [2]: https://lwn.net/Articles/751800/

In RawGit is now in a sunset phase and will soon shut down