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

[James Bennett]

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/6573aec7/attachment.html>