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

[Nick Coghlan]

On 19 August 2016 at 15:32,  <tritium-list at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia