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 <don...@stufft.io> wrote: > > > On Aug 19, 2016, at 2:53 AM, Nick Coghlan <ncogh...@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@python.org > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig