Leave pipenv in a corner until the user decides to select an interpreter

[kimadeline]

For #11127

Instead of tracking all the places that call getInterpreters on activation, and passing { onActivation: true} 15 levels deep, here's the new plan:

• remove:
  • the onActivation option
  • the registration of the IPipEnvService singleton
• add an onSuggestion option that will be true when the user clicks on the interpreter in the bottom-left corner or runs the select interpreter command. This will set a didTriggerSuggestions boolean to true the first time an interpreter is selected
• if didTriggerSuggestions is true -> set it to true inside the locators as well
• whenever a method from the pipenv locator is executed -> exit early if didTriggerSuggestions is not true

---

• Pull request represents a single change (i.e. not fixing disparate/unrelated things in a single PR).
• Title summarizes what is changing.
• Has a news entry file (remember to thank yourself!).
• Appropriate comments and documentation strings in the code.
• Has sufficient logging.
• Has telemetry for enhancements.
• Unit tests & system/integration tests are added/updated.
• Test plan is updated as appropriate.
• package-lock.json has been regenerated by running npm install (if dependencies have changed).
• The wiki is updated with any design decisions/details.

[codecov-io]

Codecov Report

Merging #11654 into master will increase coverage by 0.21%.
The diff coverage is 73.33%.

@@            Coverage Diff             @@
##           master   #11654      +/-   ##
==========================================
+ Coverage   60.70%   60.91%   +0.21%     
==========================================
  Files         626      632       +6     
  Lines       33767    34237     +470     
  Branches     4748     4845      +97     
==========================================
+ Hits        20498    20857     +359     
- Misses      12289    12369      +80     
- Partials      980     1011      +31     

Impacted Files	Coverage Δ
src/client/interpreter/contracts.ts	100.00% <ø> (ø)
src/client/interpreter/serviceRegistry.ts	100.00% <ø> (ø)
src/client/startupTelemetry.ts	30.00% <0.00%> (ø)
...reter/locators/services/cacheableLocatorService.ts	75.22% <20.00%> (-2.56%)	⬇️
...ent/interpreter/locators/services/pipEnvService.ts	83.63% <57.14%> (-0.98%)	⬇️
src/client/activation/activationManager.ts	95.37% <100.00%> (ø)
...ication/diagnostics/checks/macPythonInterpreter.ts	84.84% <100.00%> (ø)
...entActivationProviders/pipEnvActivationProvider.ts	64.28% <100.00%> (ø)
...c/client/interpreter/autoSelection/rules/system.ts	100.00% <100.00%> (ø)
...uration/interpreterSelector/interpreterSelector.ts	85.18% <100.00%> (ø)
... and 38 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f4c1ac3...1c5c0a2. Read the comment docs.

[karrtikr]

I noticed the class PipEnvService is being registered twice.

    serviceManager.addSingleton<IInterpreterLocatorService>(IInterpreterLocatorService, PipEnvService, PIPENV_SERVICE);
    serviceManager.addSingleton<IInterpreterLocatorService>(IPipEnvService, PipEnvService);

You're making sure that it doesn't get invoked using IInterpreterLocatorService, but it can still get invoked when IPipEnvService is injected somewhere (for instance)

Please remove the redundant registration using IPipEnvService and replace it with IInterpreterLocatorService.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
0 Code Smells

No Coverage information
0.0% Duplication

[karrtikr]

LGTM