On 19 August 2016 at 15:32, <tritium-l...@sdamon.com> wrote: > From: Distutils-SIG [mailto:distutils-sig-bounces+tritium- >> Alternatively, we could simply not worry about a user level flag, and >> just have a project level flag that's set to "No legacy formats" by >> default for new projects - new users won't have any incentive to >> change it, while existing users can change it (at least for the time >> being) if that suits their workflow. > > Well... what if I am a new user, opening a new project to work with legacy > systems?
*If* we went down the sunsetting path I suggested (which is by no means a given, as even though I think it's an option worth discussing, it still adds complexity and controversy for debatable benefit), then the expectation would be that anyone in this situation will either be explicitly tasked with modernising their infrastructure, or else working with an existing maintainer of the legacy infrastructure that can configure these newly created legacy projects appropriately. Folks that *don't* have a previous maintainer to help out and *also* don't have permission to modernise their infrastructure to align with current community expectations would then have to go to battle with their Finance department (since an active unwillingness to modernise toolchains almost always indicates the presence of a Finance department) to argue for investment in tooling modernisation, rather than expecting the open source community to help them workaround their organisational dysfunction indefinitely. > How is it fair to me that I didn't get to the game in time to have > my files accepted and the old-timers get to have theirs accepted? The UX concern with leaving it enabled as a config option for everyone is that we potentially miss out on the main goals of the change: simplification of the new user experience, and simplification of future tooling development. Instead, we may accidentally make the new user experience *more complicated*, as there's now another project config option for them to learn about. Configuration options should always be considered bad by default - they complicate test matrices, they complicate maintenance (of both the service itself and of other tools that interoperate with it), they complicate documentation, and they complicate the learning process. Sometimes their benefits outweigh those inherent disadvantages, but "This behaviour will not be configurable" remains the default position (otherwise we'd never get anything done in software at all) Now, sometimes providing a config option to re-enable deprecated legacy behaviour is a useful transition tool, but there still needs to be clear guidance given to authors of documentation and developers of related tools that there's no need for them to cover or support that legacy behaviour if they don't want to. > If we > shut it off for everyone, its fair. If we let anyone turn it back on, its > fair. I think this is exemplary of a trend on this sig - there is a > contingent that wants to assume things about the intent of project > maintainers, and I think that's the wrong thing to do. I don't - as the design authority for PyPI, we're responsible for a core part of the user experience of newcomers to the Python ecosystem, and we need to take that responsibility seriously. The key implication of that responsibility is an obligation to keep a close eye on the overall cognitive complexity of our toolchain, which is still mindbendingly complicated, despite the significant improvements over the past few years. In particular, we need to pay attention to the cases where low feature usage metrics from PyPI indicate the possible presence of legacy features that are making the new user experience and the toolchain maintenance process more complicated without providing a sufficient pay-off in increased power and flexibility for software publishers to justify those complications. > If we want to trim the acceptable formats for distribution to make pypi et. > al. easier to maintain, then that's fine. Do it. Or don't do it. Don't > selectively do it. 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. That said, allowing new users to opt-in to the feature (for as long as it sticks around) would be simpler than preventing them, so it's likely a better option from a pure maintainability perspective, without even considering whether or not it's fair to new users to prevent them from opting in to practices we're in the process of removing from the toolchain. In my view, the purpose of PyPI is to provide Pythonistas with a straighforward mechanism to publish open source software if they choose to do so. Fairness in an abstract sense doesn't really enter into it for me - the question I ask myself is "Will this change have a long term net impact of making it easier for more Pythonistas to publish and readily reuse more open source software?". Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
