[Distutils] Deprecating little used file types/extensions on PyPI?
dholth at gmail.com
Fri Aug 19 08:46:33 EDT 2016
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
> 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
> 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 .
> * All sdist extensions besides .tar.gz.
> That prevents new (and existing) projects from getting to a point where
> depend on something that is going away when they previously didn’t and
> existing projects a chance to update their automation and what not to
> this scenario.
>  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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG