RE: " So basically you'd remove the whole feature just cause one package no
one installs abuses it. Doesn't make sense."

No, the point being made is *at least* one package that was found on PyPI
is abusing it, so it exists and we need to consider the possibility others
are also abusing the feature.

On Thu, Mar 7, 2019 at 10:22 AM Anthony Sottile <report@bugs.python.org>
wrote:

>
> Anthony Sottile <asottile@umich.edu> added the comment:
>
> >>> I should have to start that package somehow.
> >>
> >> `pip install` is a pretty good opt-in already imo
> >
> > Except that it conflates responsibilities.  I may not want to opt into
> coverage even being loaded in my application because I’m not going to use
> it and it has a negative impact on my application’s start up time.  Yet
> because you’re on the same machine and you pip installed it, I have no
> choice but to pay those costs, which I haven’t explicitly opted in to.
>
> At least for the coverage plugins there is a required opt in from
> environment variable (as shown above).

For the ones you know about. Dealing with abuse of functionality isn't
about what common practice is, but what a bad actor may do.

> Though the startup cost is a good point.  Perhaps I'm of the minority but
> I use virtualenvs for everything so I haven't even been considering the
> system python.
>

Trust me, from my perspective of the Python extension for VS Code you
cannot ignore system installs.