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

[Daniel Holth]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160819/fb14a8e2/attachment-0001.html>