Skip to content

Conversation

@lzybkr
Copy link
Contributor

@lzybkr lzybkr commented Dec 29, 2017

PR Summary

Instead of building PSReadLine from this repo, pull it from the gallery.

This pulls v2.0 of PSReadLine which does have documented breaking changes from v1.2, but the risk is small - the features that have changed are typically only used in a profile and aren't used all that often anyway.

Fix #996

Hardcodes version of modules pulled from PSGallery

PR Checklist

Note: Please mark anything not applicable to this PR NA.

@lzybkr
Copy link
Contributor Author

lzybkr commented Dec 29, 2017

I tested these changes locally and had no problems building (I didn't run tests though.)

The CI failures show 2 problems:

  1. If restoring a modules fails, tests probably should not run.
  2. We rely on PowerShellGet to build. This is unnecessary, we could use nuget directly.

I'd like some feedback on 2 - should we update PowerShellGet as part of the build, or just use nuget?

@TravisEz13 TravisEz13 added the Breaking-Change breaking change that may affect users label Jan 2, 2018
build.psm1 Outdated
Copy link
Member

Choose a reason for hiding this comment

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

This is causing failures

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, I know, see my request for feedback here.

Copy link
Member

@TravisEz13 TravisEz13 Jan 2, 2018

Choose a reason for hiding this comment

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

Also, We should only do this (restore a PreRelease module) if needed.

@TravisEz13
Copy link
Member

It is very difficult to use NuGet directly across platforms. Please update PowerShellGet

@SteveL-MSFT SteveL-MSFT added this to the 6.1.0-MQ milestone Jan 2, 2018
@SteveL-MSFT
Copy link
Member

I think we can take this early for 6.1.0, but we should stick with the released version of PSReadline for 6.0.0-GA

@lzybkr lzybkr force-pushed the pull_psreadline branch 3 times, most recently from e890b8d to 3f39977 Compare January 8, 2018 05:45
Instead of building PSReadLine from this repo, pull it from the gallery.

Fix PowerShell#996
@lzybkr
Copy link
Contributor Author

lzybkr commented Jan 8, 2018

@TravisEz13 - I tried updating PowerShellGet, but in the end it was easier to use nuget (indirectly, via a csproj) and copy out of the nuget cache.

It looks like everything passes now, so I think this can be merged.

Note that PSReadLine will no longer be cross-gen'd after this PR, so if you merge, I'd open an issue to track adding a call to crossgen for PSReadLine - I'm not sure when I'll get a chance to do that.


Remove-Item -Force -ErrorAction Ignore -Recurse "$Destination/$name"
New-Item -Path $dest -ItemType Directory -Force -ErrorAction Stop > $null
$dontCopy = '*.nupkg', '*.nupkg.sha512', '*.nuspec', 'System.Runtime.InteropServices.RuntimeInformation.dll'
Copy link
Member

Choose a reason for hiding this comment

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

This is replicating powershellget behavior which may change over time. I'd rather not do this if we don't have to.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I get that, but this was easier to make work and has less impact on the user's environment or build machine.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Also notice how much less code there is doing it this way - I think that's valuable too.

@TravisEz13
Copy link
Member

What was the issue with PowerShellGet? Can we investigate and fix that issue?

build.psm1 Outdated
# These modules are restored to the global nuget package cache at the
# same time we restore nuget packages to build PowerShell, we just
# copy them from the cache to the final layout location now.
$modules = @(
Copy link
Member

Choose a reason for hiding this comment

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

$modules seems not used anywhere.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right, I'll remove it.

<ProjectReference Include="..\Microsoft.PowerShell.ConsoleHost\Microsoft.PowerShell.ConsoleHost.csproj" />
<ProjectReference Include="..\Microsoft.PowerShell.Security\Microsoft.PowerShell.Security.csproj" />
<ProjectReference Include="..\System.Management.Automation\System.Management.Automation.csproj" />
<ProjectReference Include="..\Modules\PSGalleryModules.csproj" />
Copy link
Member

Choose a reason for hiding this comment

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

When building nuget packages for individual assemblies, I think this reference will cause a nuget package to be generated for PSGalleryModules.csproj and the generated Microsoft.PowerShell.SDK package will have a reference to the PSGalleryModules nuget package. We should avoid creating the unneeded PSGalleryModules nuget package.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Indeed, I'll remove this and do the restore on PSGalleryModules.csproj explicitly.

@lzybkr
Copy link
Contributor Author

lzybkr commented Jan 11, 2018

PowerShellGet would update successfully, but I would get errors from PackageManagement, presumably because it is a binary module and the newly installed version wasn't being picked up.

I considered "fixing" that by running the update in a child process, but:

  • Running in a child process can be harder to debug, harder to pass parameters (no live objects e.g.)
  • I just think it's cleaner to use nuget for the package restore, e.g. the packages are cached, so you don't pull the package every time you build.

@lzybkr
Copy link
Contributor Author

lzybkr commented Jan 11, 2018

I updated to address the feedback.

I don't plan on changing back to using PowerShellGet - I think this approach could be turned on by default - we can rely on the nuget cache instead of fetching from the network on every build.

Also regarding this approach versus using PowerShellGet - in my opinion:

  • Either way, we need some logic to remove something, PowerShellGet artifacts or nuget artifacts
  • The build fails quickly this way if the package is missing - the previous way the build succeeds and you don't discover a missing module until running tests, assuming there are tests.
  • With a csproj, the dependencies are easier to express, maybe not in the SDK csproj, but the dependency is more discoverable than being hidden in build.psm1.

@TravisEz13 TravisEz13 merged commit beffdcf into PowerShell:master Jan 20, 2018
@adityapatwardhan
Copy link
Member

Reverting this change as Console tests are failing on non-windows. The failure is: An error has occurred that was not properly handled. Additional information is shown below. The PowerShell process will exit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Breaking-Change breaking change that may affect users

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Export PSReadLine to changes to public project

5 participants