[Distutils] Deprecating little used file types/extensions on PyPI?

Daniel Holth dholth at gmail.com
Fri Aug 19 10:23:22 EDT 2016

The only issue I have with the proposal is the removal of .zip sdists
because I would personally be inconvenienced by the removal of .zip.
Consider that "setup.py sdist" produces .zip by default on Windows.

On Fri, Aug 19, 2016 at 9:36 AM James Bennett <ubernostrum at gmail.com> wrote:

> Every new configuration option added to a piece of software represents two
> opportunities:
> 1. An opportunity to introduce exciting new bugs.
> 2. An opportunity to introduce exciting new ways for users to click the
> thing that does the exact opposite of what they wanted to do.
> The proliferation of different package formats is not a sign of
> innovation; it's a sign of the desperation induced by how bad Python
> packaging was, and for how long. Now that things are in a much better
> state, it's time to remove the combinatorial explosion of opportunities for
> bugs and end-user mistakes, and be able to say clearly "here's how you
> package and distribute Python code".
> Comparing that to to "hostile architecture" is petulant and inappropriate
> and you know it.
> On Fri, Aug 19, 2016 at 5:46 AM, Daniel Holth <dholth at gmail.com> wrote:
>> Check out this Camden Bench. https://en.wikipedia.org/wiki/Camden_bench
>>  . The creators of the bench enumerated about 23 specific undesirable
>> behaviors that they feel normal benches allow (like sleeping and
>> skateboarding) and came up with a lump of concrete that you can sit on.
>> On Fri, Aug 19, 2016 at 8:14 AM Donald Stufft <donald at stufft.io> wrote:
>>> > On Aug 19, 2016, at 2:53 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> >
>>> > Unilaterally turning the feature off would be extraordinarily hostile
>>> > to current users - grace periods and sunset clauses are standard
>>> > features of change management processes for a reason, even when they
>>> > come at the cost of additional implementation complexity.
>>> This wouldn’t be a new way of handling this, when we implemented PEP 470
>>> new projects immediately got set to the “only files on PyPI mode” and had
>>> no ability to change to a different mode (no reason to present an option
>>> that was going away). Emails were sent to maintains on all projects that
>>> had an existing external link and told that in X months all their
>>> external
>>> links would be removed (which was implemented just as switching them to
>>> the
>>> “only files on PyPI mode”.
>>> Therefore, given what’s been discussed thus far, my proposal would be:
>>> Add a hidden flag, “legacy file support” on a per project basis. All new
>>> projects
>>> have this flag switched off, any existing project that has not ever
>>> uploaded a
>>> file that would use this flag has it switched off, everyone else has it
>>> switched
>>> on. Emails get sent out to maintainers of projects where it is still
>>> switched on
>>> and they’re told “In 3 months you’ll no longer be able to upload legacy
>>> file types,
>>> but all existing files uploaded will continue to exist”.
>>> Files that would fall under legacy file type:
>>> * All types except sdist, bdist_wheel, and bdist_egg [1].
>>> * All sdist extensions besides .tar.gz.
>>> That prevents new (and existing) projects from getting to a point where
>>> they
>>> depend on something that is going away when they previously didn’t and
>>> gives
>>> existing projects a chance to update their automation and what not to
>>> handle
>>> this scenario.
>>> [1] We can tackle egg at a later point, when setuptools either has
>>> support for Wheels
>>>     or is less needed.
>>>>>> Donald Stufft
>>> _______________________________________________
>>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>>> https://mail.python.org/mailman/listinfo/distutils-sig
>> _______________________________________________
>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160819/f5b5db03/attachment-0001.html>

More information about the Distutils-SIG mailing list