This is just so I remember to do this for @lzybkr.

While extracting the history and making PSReadLine build stand-alone against the public reference assemblies, I got blocked by a weird .NET possible bug. Filed dotnet/corefx#9658.

Changes have been exported, closing.

This shouldn't be closed until PSReadline has a single source of truth.

• Changes are accepted
• Package from lzybkr/PSReadline are being consumed here
• PSReadline sources are removed from this repo

Okay, well I'm at least changing over the assignee then.

After this change, the easiest way to pull the Pester module from PowerShell Gallery is to add it to the file src/Modules/PSGalleryModules.csproj but as the result,

• Pester module will be pulled every time
• the switch CI used in the functions
  • Start-PSBuild
  • Restore-PSModuleToBuild
    will be useless and have to be removed.

Another option - probably a more accurate - is to create the new one csproj file - by analogy to src/Modules/PSGalleryModules.csproj (the proposed name PSGalleryModulesCI.csproj) and add an additional parameter to the function Copy-PSGalleryModules that will contain a path to csproj file (an equivalent of the current line 2484) and call the function Copy-PSGalleryModules twice when $CI will be used.

In both options the functions

• Restore-PSPester
• Restore-GitModule
  will be removed.

What do you think? Am I right?

My comment is related to #4618.

@it-praktyk - msbuild restore caches the package locally, so if the cache already has the correct version, nothing is pulled.

Furthermore, at least in AppVeyor (I'm not sure about Travis) - the cache is saved across builds, so we shouldn't see too many pulls from CI.

I think what I did for PSReadLine can be done for Pester as well and as you point out - that would get rid of some code in build.psm1 - but I haven't looked as closely as you - maybe we don't need the -CI parameter assuming the nuget cache is working as I described.