Skip to content

Register or access old Conda locator only when not in experiment#15292

Merged
karrtikr merged 9 commits into
microsoft:mainfrom
karrtikr:condser
Feb 4, 2021
Merged

Register or access old Conda locator only when not in experiment#15292
karrtikr merged 9 commits into
microsoft:mainfrom
karrtikr:condser

Conversation

@karrtikr

@karrtikr karrtikr commented Feb 2, 2021

Copy link
Copy Markdown

Follow up work from #15276

  • Implemented CondaService using conda.ts. New code added in CondaService is mainly taken from old code in CondaLocatorService, and CondaEnvironmentLocator.
  • Register or access CondaLocatorService only when not in experiment

@karrtikr karrtikr added the no-changelog No news entry required label Feb 2, 2021
@karrtikr karrtikr changed the title Implemented CondaService using conda.ts Register or access old Conda locator only when not in experiment Feb 2, 2021
@karrtikr karrtikr marked this pull request as ready for review February 2, 2021 23:34
@codecov-io

Copy link
Copy Markdown

Codecov Report

Merging #15292 (9326f53) into main (7c7f320) will decrease coverage by 0%.
The diff coverage is 64%.

@@          Coverage Diff           @@
##            main   #15292   +/-   ##
======================================
- Coverage     64%      64%   -1%     
======================================
  Files        560      560           
  Lines      26790    26834   +44     
  Branches    3862     3867    +5     
======================================
+ Hits       17413    17436   +23     
- Misses      8660     8682   +22     
+ Partials     717      716    -1     
Impacted Files Coverage Δ
src/client/pythonEnvironments/legacyIOC.ts 37% <ø> (+<1%) ⬆️
...nments/discovery/locators/services/condaService.ts 60% <35%> (-17%) ⬇️
...mentActivationProviders/condaActivationProvider.ts 93% <90%> (+<1%) ⬆️
src/client/common/installer/condaInstaller.ts 100% <100%> (ø)
...rc/client/common/process/pythonExecutionFactory.ts 87% <100%> (+<1%) ⬆️
src/client/common/terminal/helper.ts 97% <100%> (+<1%) ⬆️
src/client/interpreter/contracts.ts 100% <0%> (ø)
src/client/interpreter/display/progressDisplay.ts 87% <0%> (+4%) ⬆️

Comment thread src/test/common/installer/moduleInstaller.unit.test.ts
condaLocatorService = mock<ICondaLocatorService>();
processLogger = mock(ProcessLogger);
experimentService = mock(ExperimentService);
when(experimentService.inExperiment(DiscoveryVariants.discoverWithFileWatching)).thenResolve(false);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the advantage of mocking false for one experiment and not the other, and of doing that vs mocking the inDiscoveryExperiment helper directly?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's because we're trying not to stub implementation details where we can, inDiscoveryExperiment in our case. And only stub where it's necessary like filesystem boundaries, env variables, etc.

What is the advantage of mocking false for one experiment and not the other

Actually I should be stubbing false for both the cases, will do.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we're trying not to stub implementation details where we can

Since we're mocking/stubbing the implementation details of inDiscoveryExperiment here, if one day it changes we'll have to change all these tests even though they don't explicitly call this method?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case it may not be much. But the advantage of that is supposed we access inExperiment API differently, without changing the overall behavior, the same tests would still hold up. In other words, tests are loosely coupled with the implementation.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if one day it changes we'll have to change all these tests even though they don't explicitly call this method

And yes, but I think that's also the right thing to do. That way we would be aware of what impact this change is having. We can take this discussion offline at this point.

Comment thread src/test/common/installer/moduleInstaller.unit.test.ts

@karthiknadig karthiknadig left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

@kimadeline kimadeline left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

still have the inDiscoveryExperiment question, but it's not blocking.

@karrtikr karrtikr merged commit 31ce50c into microsoft:main Feb 4, 2021
@karrtikr karrtikr deleted the condser branch February 4, 2021 19:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

no-changelog No news entry required

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants