python-peps/pep-0527/index.html

354 lines
29 KiB
HTML
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="color-scheme" content="light dark">
<title>PEP 527 Removing Un(der)used file types/extensions on PyPI | peps.python.org</title>
<link rel="shortcut icon" href="../_static/py.png">
<link rel="canonical" href="https://peps.python.org/pep-0527/">
<link rel="stylesheet" href="../_static/style.css" type="text/css">
<link rel="stylesheet" href="../_static/mq.css" type="text/css">
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" media="(prefers-color-scheme: light)" id="pyg-light">
<link rel="stylesheet" href="../_static/pygments_dark.css" type="text/css" media="(prefers-color-scheme: dark)" id="pyg-dark">
<link rel="alternate" type="application/rss+xml" title="Latest PEPs" href="https://peps.python.org/peps.rss">
<meta property="og:title" content='PEP 527 Removing Un(der)used file types/extensions on PyPI | peps.python.org'>
<meta property="og:description" content="This PEP recommends deprecating, and ultimately removing, support for uploading certain unused or under used file types and extensions to PyPI. In particular it recommends disallowing further uploads of any files of the types bdist_dumb, bdist_rpm, bdis...">
<meta property="og:type" content="website">
<meta property="og:url" content="https://peps.python.org/pep-0527/">
<meta property="og:site_name" content="Python Enhancement Proposals (PEPs)">
<meta property="og:image" content="https://peps.python.org/_static/og-image.png">
<meta property="og:image:alt" content="Python PEPs">
<meta property="og:image:width" content="200">
<meta property="og:image:height" content="200">
<meta name="description" content="This PEP recommends deprecating, and ultimately removing, support for uploading certain unused or under used file types and extensions to PyPI. In particular it recommends disallowing further uploads of any files of the types bdist_dumb, bdist_rpm, bdis...">
<meta name="theme-color" content="#3776ab">
</head>
<body>
<svg xmlns="http://www.w3.org/2000/svg" style="display: none;">
<symbol id="svg-sun-half" viewBox="0 0 24 24" pointer-events="all">
<title>Following system colour scheme</title>
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none"
stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
<circle cx="12" cy="12" r="9"></circle>
<path d="M12 3v18m0-12l4.65-4.65M12 14.3l7.37-7.37M12 19.6l8.85-8.85"></path>
</svg>
</symbol>
<symbol id="svg-moon" viewBox="0 0 24 24" pointer-events="all">
<title>Selected dark colour scheme</title>
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none"
stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
<path stroke="none" d="M0 0h24v24H0z" fill="none"></path>
<path d="M12 3c.132 0 .263 0 .393 0a7.5 7.5 0 0 0 7.92 12.446a9 9 0 1 1 -8.313 -12.454z"></path>
</svg>
</symbol>
<symbol id="svg-sun" viewBox="0 0 24 24" pointer-events="all">
<title>Selected light colour scheme</title>
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none"
stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
<circle cx="12" cy="12" r="5"></circle>
<line x1="12" y1="1" x2="12" y2="3"></line>
<line x1="12" y1="21" x2="12" y2="23"></line>
<line x1="4.22" y1="4.22" x2="5.64" y2="5.64"></line>
<line x1="18.36" y1="18.36" x2="19.78" y2="19.78"></line>
<line x1="1" y1="12" x2="3" y2="12"></line>
<line x1="21" y1="12" x2="23" y2="12"></line>
<line x1="4.22" y1="19.78" x2="5.64" y2="18.36"></line>
<line x1="18.36" y1="5.64" x2="19.78" y2="4.22"></line>
</svg>
</symbol>
</svg>
<script>
document.documentElement.dataset.colour_scheme = localStorage.getItem("colour_scheme") || "auto"
</script>
<section id="pep-page-section">
<header>
<h1>Python Enhancement Proposals</h1>
<ul class="breadcrumbs">
<li><a href="https://www.python.org/" title="The Python Programming Language">Python</a> &raquo; </li>
<li><a href="../pep-0000/">PEP Index</a> &raquo; </li>
<li>PEP 527</li>
</ul>
<button id="colour-scheme-cycler" onClick="setColourScheme(nextColourScheme())">
<svg aria-hidden="true" class="colour-scheme-icon-when-auto"><use href="#svg-sun-half"></use></svg>
<svg aria-hidden="true" class="colour-scheme-icon-when-dark"><use href="#svg-moon"></use></svg>
<svg aria-hidden="true" class="colour-scheme-icon-when-light"><use href="#svg-sun"></use></svg>
<span class="visually-hidden">Toggle light / dark / auto colour theme</span>
</button>
</header>
<article>
<section id="pep-content">
<h1 class="page-title">PEP 527 Removing Un(der)used file types/extensions on PyPI</h1>
<dl class="rfc2822 field-list simple">
<dt class="field-odd">Author<span class="colon">:</span></dt>
<dd class="field-odd">Donald Stufft &lt;donald&#32;&#97;t&#32;stufft.io&gt;</dd>
<dt class="field-even">BDFL-Delegate<span class="colon">:</span></dt>
<dd class="field-even">Alyssa Coghlan &lt;ncoghlan&#32;&#97;t&#32;gmail.com&gt;</dd>
<dt class="field-odd">Discussions-To<span class="colon">:</span></dt>
<dd class="field-odd"><a class="reference external" href="https://mail.python.org/archives/list/distutils-sig&#64;python.org/">Distutils-SIG list</a></dd>
<dt class="field-even">Status<span class="colon">:</span></dt>
<dd class="field-even"><abbr title="Accepted and implementation complete, or no longer active">Final</abbr></dd>
<dt class="field-odd">Type<span class="colon">:</span></dt>
<dd class="field-odd"><abbr title="Normative PEP with a new feature for Python, implementation change for CPython or interoperability standard for the ecosystem">Standards Track</abbr></dd>
<dt class="field-even">Topic<span class="colon">:</span></dt>
<dd class="field-even"><a class="reference external" href="../topic/packaging/">Packaging</a></dd>
<dt class="field-odd">Created<span class="colon">:</span></dt>
<dd class="field-odd">23-Aug-2016</dd>
<dt class="field-even">Post-History<span class="colon">:</span></dt>
<dd class="field-even">23-Aug-2016</dd>
<dt class="field-odd">Resolution<span class="colon">:</span></dt>
<dd class="field-odd"><a class="reference external" href="https://mail.python.org/pipermail/distutils-sig/2016-September/029624.html">Distutils-SIG message</a></dd>
</dl>
<hr class="docutils" />
<section id="contents">
<details><summary>Table of Contents</summary><ul class="simple">
<li><a class="reference internal" href="#abstract">Abstract</a></li>
<li><a class="reference internal" href="#rationale">Rationale</a><ul>
<li><a class="reference internal" href="#file-formats">File Formats</a><ul>
<li><a class="reference internal" href="#bdist-dumb">bdist_dumb</a></li>
<li><a class="reference internal" href="#bdist-rpm">bdist_rpm</a></li>
<li><a class="reference internal" href="#bdist-dmg-bdist-msi-and-bdist-wininst">bdist_dmg, bdist_msi, and bdist_wininst</a></li>
</ul>
</li>
<li><a class="reference internal" href="#file-extensions">File Extensions</a></li>
<li><a class="reference internal" href="#limiting-number-of-sdists-per-release">Limiting number of sdists per release</a></li>
</ul>
</li>
<li><a class="reference internal" href="#removal-process">Removal Process</a></li>
<li><a class="reference internal" href="#copyright">Copyright</a></li>
</ul>
</details></section>
<section id="abstract">
<h2><a class="toc-backref" href="#abstract" role="doc-backlink">Abstract</a></h2>
<p>This PEP recommends deprecating, and ultimately removing, support for uploading
certain unused or under used file types and extensions to PyPI. In particular
it recommends disallowing further uploads of any files of the types
<code class="docutils literal notranslate"><span class="pre">bdist_dumb</span></code>, <code class="docutils literal notranslate"><span class="pre">bdist_rpm</span></code>, <code class="docutils literal notranslate"><span class="pre">bdist_dmg</span></code>, <code class="docutils literal notranslate"><span class="pre">bdist_msi</span></code>, and
<code class="docutils literal notranslate"><span class="pre">bdist_wininst</span></code>, leaving PyPI to only accept new uploads of the <code class="docutils literal notranslate"><span class="pre">sdist</span></code>,
<code class="docutils literal notranslate"><span class="pre">bdist_wheel</span></code>, and <code class="docutils literal notranslate"><span class="pre">bdist_egg</span></code> file types.</p>
<p>In addition, this PEP proposes removing support for new uploads of sdists using
the <code class="docutils literal notranslate"><span class="pre">.tar</span></code>, <code class="docutils literal notranslate"><span class="pre">.tar.bz2</span></code>, <code class="docutils literal notranslate"><span class="pre">.tar.xz</span></code>, <code class="docutils literal notranslate"><span class="pre">.tar.Z</span></code>, <code class="docutils literal notranslate"><span class="pre">.tgz</span></code>, <code class="docutils literal notranslate"><span class="pre">.tbz</span></code>, and
any other extension besides <code class="docutils literal notranslate"><span class="pre">.tar.gz</span></code> and <code class="docutils literal notranslate"><span class="pre">.zip</span></code>.</p>
<p>Finally, this PEP also proposes limiting the number of allowed sdist uploads
for each individual release of a project on PyPI to one instead of one for each
allowed extension.</p>
</section>
<section id="rationale">
<h2><a class="toc-backref" href="#rationale" role="doc-backlink">Rationale</a></h2>
<section id="file-formats">
<h3><a class="toc-backref" href="#file-formats" role="doc-backlink">File Formats</a></h3>
<p>Currently PyPI supports the following file types:</p>
<ul class="simple">
<li><code class="docutils literal notranslate"><span class="pre">sdist</span></code></li>
<li><code class="docutils literal notranslate"><span class="pre">bdist_wheel</span></code></li>
<li><code class="docutils literal notranslate"><span class="pre">bdist_egg</span></code></li>
<li><code class="docutils literal notranslate"><span class="pre">bdist_wininst</span></code></li>
<li><code class="docutils literal notranslate"><span class="pre">bdist_msi</span></code></li>
<li><code class="docutils literal notranslate"><span class="pre">bdist_dmg</span></code></li>
<li><code class="docutils literal notranslate"><span class="pre">bdist_rpm</span></code></li>
<li><code class="docutils literal notranslate"><span class="pre">bdist_dumb</span></code></li>
</ul>
<p>However, these different types of files have varying amounts of usefulness or
general use in the ecosystem. Continuing to support them adds a maintenance
burden on PyPI as well as tool authors and incurs a cost in both bandwidth and
disk space not only on PyPI itself, but also on any mirrors of PyPI.</p>
<p>Python packaging is a multi-level ecosystem where PyPI is primarily suited and
used to distribute virtual environment compatible packages directly from their
respective project owners. These packages are then consumed either directly
by end-users, or by downstream distributors that take these packages and turn
them into their respective system level packages (such as RPM, deb, MSI, etc).</p>
<p>While PyPI itself only directly works with these Python specific but platform
agnostic packages, we encourage community-driven and commercial conversions of
these packages to downstream formats for particular target environments, like:</p>
<ul class="simple">
<li>The conda cross-platform data analysis ecosystem (conda-forge)</li>
<li>The deb based Linux ecosystem (Debian, Ubuntu, etc)</li>
<li>The RPM based Linux ecosystem (Fedora, openSuSE, Mageia, etc)</li>
<li>The homebrew, MacPorts and fink ecosystems for Mac OS X</li>
<li>The Windows Package Management ecosystem (NuGet, Chocolatey, etc)</li>
<li>3rd party creation of Windows MSIs and installers (e.g. Christoph Gohlkes
work at <a class="reference external" href="http://www.lfd.uci.edu/~gohlke/pythonlibs/">http://www.lfd.uci.edu/~gohlke/pythonlibs/</a> )</li>
<li>other commercial redistribution formats (ActiveStates PyPM, Enthought
Canopy, etc)</li>
<li>other open source community redistribution formats (Nix, Gentoo, Arch, *BSD,
etc)</li>
</ul>
<p>It is the belief of this PEP that the entire ecosystem is best supported by
keeping PyPI focused on the platform agnostic formats, where the limited amount
of time by volunteers can be best used instead of spreading the available time
out amongst several platforms. Further more, this PEP believes that the people
best positioned to provide well integrated packages for a particular platform
are people focused on that platform, and not across all possible platforms.</p>
<section id="bdist-dumb">
<h4><a class="toc-backref" href="#bdist-dumb" role="doc-backlink">bdist_dumb</a></h4>
<p>As its name implies, <code class="docutils literal notranslate"><span class="pre">bdist_dumb</span></code> is not a very complex format, however it
is so simple as to be worthless for actual usage.</p>
<p>For instance, if youre using something like pyenv on macOS and youre building
a library using Python 3.5, then <code class="docutils literal notranslate"><span class="pre">bdist_dumb</span></code> will produce a <code class="docutils literal notranslate"><span class="pre">.tar.gz</span></code> file
named something like <code class="docutils literal notranslate"><span class="pre">exampleproject-1.0.macosx-10.11-x86_64.tar.gz</span></code>. Right
off the bat this file name is somewhat difficult to differentiate from an
<code class="docutils literal notranslate"><span class="pre">sdist</span></code> since they both use the same file extension (and with the legacy pre
<a class="pep reference internal" href="../pep-0440/" title="PEP 440 Version Identification and Dependency Specification">PEP 440</a> versions, <code class="docutils literal notranslate"><span class="pre">1.0-macosx-10.11-x86_64</span></code> is a valid, although quite silly,
version number). However, once you open up the created <code class="docutils literal notranslate"><span class="pre">.tar.gz</span></code>, youd find
that there is no metadata inside that could be used for things like dependency
discovery and in fact, it is quite simply a tarball containing hardcoded paths
to wherever files would have been installed on the computer creating the
<code class="docutils literal notranslate"><span class="pre">bdist_dumb</span></code>. Going back to our pyenv on macOS example, this means that if I
created it, it would contain files like:</p>
<p><code class="docutils literal notranslate"><span class="pre">Users/dstufft/.pyenv/versions/3.5.2/lib/python3.5/site-packages/example.py</span></code></p>
</section>
<section id="bdist-rpm">
<h4><a class="toc-backref" href="#bdist-rpm" role="doc-backlink">bdist_rpm</a></h4>
<p>The <code class="docutils literal notranslate"><span class="pre">bdist_rpm</span></code> format on PyPI allows people to upload <code class="docutils literal notranslate"><span class="pre">.rpm</span></code> files for
end users to manually download by hand and then manually install by hand.
However, the common usage of <code class="docutils literal notranslate"><span class="pre">rpm</span></code> is with a specially designed repository
that allows automatic installation of dependencies, upgrades, etc which PyPI
does not provide. Thus, it is a type of file that is barely being used on PyPI
with only ~460 files of this type having been uploaded to PyPI (out a total of
662,544).</p>
<p>In addition, services like <a class="reference external" href="https://copr.fedorainfracloud.org/">COPR</a> provide
a better supported mechanism for publishing and using RPM files than were ever
likely to get on PyPI.</p>
</section>
<section id="bdist-dmg-bdist-msi-and-bdist-wininst">
<h4><a class="toc-backref" href="#bdist-dmg-bdist-msi-and-bdist-wininst" role="doc-backlink">bdist_dmg, bdist_msi, and bdist_wininst</a></h4>
<p>The <code class="docutils literal notranslate"><span class="pre">bdist_dmg</span></code>, <code class="docutils literal notranslate"><span class="pre">bdist_msi</span></code>, and <code class="docutils literal notranslate"><span class="pre">bdist_winist</span></code> formats are similar in
that they are an OS specific installer that will only install a library into an
environment and are not designed for real user facing installs of applications
(which would require things like bundling a Python interpreter and the like).</p>
<p>Out of these three, the usage for <code class="docutils literal notranslate"><span class="pre">bdist_dmg</span></code> and <code class="docutils literal notranslate"><span class="pre">bdist_msi</span></code> is very low,
with only ~500 <code class="docutils literal notranslate"><span class="pre">bdist_msi</span></code> files and ~50 <code class="docutils literal notranslate"><span class="pre">bdist_dmg</span></code> files having been
uploaded to PyPI. The <code class="docutils literal notranslate"><span class="pre">bdist_wininst</span></code> format has more use, with ~14,000 files
having ever been uploaded to PyPI.</p>
<p>Its quite easy to look at the low usage of <code class="docutils literal notranslate"><span class="pre">bdist_dmg</span></code> and <code class="docutils literal notranslate"><span class="pre">bdist_msi</span></code> and
conclude that removing them will be fairly low impact, however
<code class="docutils literal notranslate"><span class="pre">bdist_wininst</span></code> has several orders of magnitude more usage. This is somewhat
misleading though, because although it has more people <em>uploading</em> those files
the actual usage of those uploaded files is fairly low. Taking a look at the
previous 30 days, we can see that 90% of all downloads of <code class="docutils literal notranslate"><span class="pre">bdist_winist</span></code>
files from PyPI were generated by the mirroring infrastructure and 7% of them
were generated by setuptools (which can currently be better covered by
<code class="docutils literal notranslate"><span class="pre">bdist_egg</span></code> files).</p>
<p>Given the small number of files uploaded for <code class="docutils literal notranslate"><span class="pre">bdist_dmg</span></code> and <code class="docutils literal notranslate"><span class="pre">bdist_msi</span></code>
and that <code class="docutils literal notranslate"><span class="pre">bdist_wininst</span></code> is largely existing to either consume bandwidth and
disk space via the mirroring infrastructure <em>or</em> could be trivially replaced
with <code class="docutils literal notranslate"><span class="pre">bdist_egg</span></code>, this PEP proposes to include these three formats in the
list of those to be disallowed.</p>
</section>
</section>
<section id="file-extensions">
<h3><a class="toc-backref" href="#file-extensions" role="doc-backlink">File Extensions</a></h3>
<p>Currently <code class="docutils literal notranslate"><span class="pre">sdist</span></code> supports a wide variety of file extensions like <code class="docutils literal notranslate"><span class="pre">.tar.gz</span></code>,
<code class="docutils literal notranslate"><span class="pre">.tar</span></code>, <code class="docutils literal notranslate"><span class="pre">.tar.bz2</span></code>, <code class="docutils literal notranslate"><span class="pre">.tar.xz</span></code>, <code class="docutils literal notranslate"><span class="pre">.zip</span></code>, <code class="docutils literal notranslate"><span class="pre">.tar.Z</span></code>, <code class="docutils literal notranslate"><span class="pre">.tgz</span></code>, and
<code class="docutils literal notranslate"><span class="pre">.tbz</span></code>. However, of those the only extensions which get anything more than
negligible usage is <code class="docutils literal notranslate"><span class="pre">.tar.gz</span></code> with 444,338 sdists currently, <code class="docutils literal notranslate"><span class="pre">.zip</span></code> with
58,774 sdists currently, and <code class="docutils literal notranslate"><span class="pre">.tar.bz2</span></code> with 3,265 sdists currently.</p>
<p>Having multiple formats accepted requires tooling both within PyPI and outside
of PyPI to handle all of the various extensions that <em>might</em> be used (even if
nobody is currently using them). This doesnt only affect PyPI, but ripples out
throughout the ecosystem. In addition, the different formats all have different
requirements for what optional C libraries Python was linked against and
different requirements for what versions of Python they support. In addition,
multiple formats also create a weird situation where there may be two
<code class="docutils literal notranslate"><span class="pre">sdist</span></code> files for a particular project/release with subtly different content.</p>
<p>Its easy to advocate that anything outside of <code class="docutils literal notranslate"><span class="pre">.tar.gz</span></code>, <code class="docutils literal notranslate"><span class="pre">.zip</span></code>, and
<code class="docutils literal notranslate"><span class="pre">.tar.bz2</span></code> should be disallowed. Outside of a tiny handful, nobody has
actively been uploading these other types of files in the ~15 years of PyPIs
existence so theyve obviously not been particularly useful. In addition, while
<code class="docutils literal notranslate"><span class="pre">.tar.xz</span></code> is theoretically a nicer format than the other <code class="docutils literal notranslate"><span class="pre">.tar.*</span></code> formats
due to the better compression ratio achieved by LZMA, it is only available in
Python 3.3+ and has an optional dependency on the lzma C library.</p>
<p>Looking at the three extensions we <em>do</em> have in current use, its also fairly
easy to conclude that <code class="docutils literal notranslate"><span class="pre">.tar.bz2</span></code> can be disallowed as well. It has a fairly
small number of files ever uploaded with it and it requires an additional
optional C library to handle the bzip2 compression.</p>
<p>Finally we get down to <code class="docutils literal notranslate"><span class="pre">.tar.gz</span></code> and <code class="docutils literal notranslate"><span class="pre">.zip</span></code>. Looking at the pure numbers
for these two, we can see that <code class="docutils literal notranslate"><span class="pre">.tar.gz</span></code> is by far the most uploaded format,
with 444,338 total uploaded compared to <code class="docutils literal notranslate"><span class="pre">.zip</span></code>s 58,774 and on POSIX
operating systems <code class="docutils literal notranslate"><span class="pre">.tar.gz</span></code> is also the default produced by all currently
released versions of Python and setuptools. In addition, these two file types
both use the same C library (<code class="docutils literal notranslate"><span class="pre">zlib</span></code>) which is also required for
<code class="docutils literal notranslate"><span class="pre">bdist_wheel</span></code> and <code class="docutils literal notranslate"><span class="pre">bdist_egg</span></code>. The two wrinkles with deciding between
<code class="docutils literal notranslate"><span class="pre">.tar.gz</span></code> and <code class="docutils literal notranslate"><span class="pre">.zip</span></code> is that while on POSIX operating systems <code class="docutils literal notranslate"><span class="pre">.tar.gz</span></code>
is the default, on Windows <code class="docutils literal notranslate"><span class="pre">.zip</span></code> is the default and the <code class="docutils literal notranslate"><span class="pre">bdist_wheel</span></code>
format also uses zip.</p>
<p>Instead of trying to standardize on either <code class="docutils literal notranslate"><span class="pre">.tar.gz</span></code> or <code class="docutils literal notranslate"><span class="pre">.zip</span></code>, this PEP
proposes that we allow <em>either</em> <code class="docutils literal notranslate"><span class="pre">.tar.gz</span></code> or <code class="docutils literal notranslate"><span class="pre">.zip</span></code> for sdists.</p>
</section>
<section id="limiting-number-of-sdists-per-release">
<h3><a class="toc-backref" href="#limiting-number-of-sdists-per-release" role="doc-backlink">Limiting number of sdists per release</a></h3>
<p>A sdist on PyPI should be a single source of truth for a particular release of
software. However, currently PyPI allows you to upload one sdist for each of
the sdist file extensions it allows. Currently this allows something like 10
different sdists for a project, but even with this PEP it allows two different
sources of truth for a single version. Having multiple sdists oftentimes can
account for strange bugs that only expose themselves based on which sdist that
the person used.</p>
<p>To resolve this, this PEP proposes to allow one, and only one, sdist per
release of a project.</p>
</section>
</section>
<section id="removal-process">
<h2><a class="toc-backref" href="#removal-process" role="doc-backlink">Removal Process</a></h2>
<p>This PEP does <strong>NOT</strong> propose removing any existing files from PyPI, only
disallowing new ones from being uploaded. This restriction will be phased in on
a per-project basis to allow projects to adjust to the new restrictions where
applicable.</p>
<p>First, any <em>existing</em> projects will be flagged to allow legacy file types to be
uploaded, and any project without that flag (i.e. new projects) will not be
able to upload anything but <code class="docutils literal notranslate"><span class="pre">sdist</span></code> with a <code class="docutils literal notranslate"><span class="pre">.tar.gz</span></code> or <code class="docutils literal notranslate"><span class="pre">.zip</span></code> extension,
<code class="docutils literal notranslate"><span class="pre">bdist_wheel</span></code>, and <code class="docutils literal notranslate"><span class="pre">bdist_egg</span></code>. Then, any existing projects that have never
uploaded a file that requires the legacy file type flag will have that flag
removed, also making them fall under the new restrictions. Finally, an email
will be generated to the maintainers of all projects still given the legacy
flag, which will inform them of the upcoming new restrictions on uploads and
tell them that these restrictions will be applied to future uploads to their
projects starting in 1 month. Finally, after 1 month all projects will have the
legacy file type flag removed, and support for uploading these types of files
will cease to exist on PyPI.</p>
<p>This plan should provide minimal disruption since it does not remove any
existing files, and the types of files it does prevent from being uploaded are
either not particularly useful (or used) types of files <em>or</em> they can continue
to upload a similar type of file with a slight change to their process.</p>
</section>
<section id="copyright">
<h2><a class="toc-backref" href="#copyright" role="doc-backlink">Copyright</a></h2>
<p>This document has been placed in the public domain.</p>
</section>
</section>
<hr class="docutils" />
<p>Source: <a class="reference external" href="https://github.com/python/peps/blob/main/peps/pep-0527.rst">https://github.com/python/peps/blob/main/peps/pep-0527.rst</a></p>
<p>Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0527.rst">2023-10-11 12:05:51 GMT</a></p>
</article>
<nav id="pep-sidebar">
<h2>Contents</h2>
<ul>
<li><a class="reference internal" href="#abstract">Abstract</a></li>
<li><a class="reference internal" href="#rationale">Rationale</a><ul>
<li><a class="reference internal" href="#file-formats">File Formats</a><ul>
<li><a class="reference internal" href="#bdist-dumb">bdist_dumb</a></li>
<li><a class="reference internal" href="#bdist-rpm">bdist_rpm</a></li>
<li><a class="reference internal" href="#bdist-dmg-bdist-msi-and-bdist-wininst">bdist_dmg, bdist_msi, and bdist_wininst</a></li>
</ul>
</li>
<li><a class="reference internal" href="#file-extensions">File Extensions</a></li>
<li><a class="reference internal" href="#limiting-number-of-sdists-per-release">Limiting number of sdists per release</a></li>
</ul>
</li>
<li><a class="reference internal" href="#removal-process">Removal Process</a></li>
<li><a class="reference internal" href="#copyright">Copyright</a></li>
</ul>
<br>
<a id="source" href="https://github.com/python/peps/blob/main/peps/pep-0527.rst">Page Source (GitHub)</a>
</nav>
</section>
<script src="../_static/colour_scheme.js"></script>
<script src="../_static/wrap_tables.js"></script>
<script src="../_static/sticky_banner.js"></script>
</body>
</html>