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 <ubernost...@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 <dho...@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 <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 >> >> >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
