Skip to content

Conversation

@KevinRansom
Copy link
Contributor

With the current implementation of the package manager resolution is delayed until code is generated and executed. This has the side effect that errors are not displayed until later than expected.

It is commonly believed by developers that:
#r "nuget:FSharp.Data";; should resolve and display errors immediately.

It is somewhat jarring to see:

Microsoft (R) F# Interactive version 10.10.0.0 for F# 4.7
Copyright (c) Microsoft Corporation. All Rights Reserved.

For help type #help;;

> #r "nuget:FSharp.DoTheWrongThing";;
>
-
- ;;

and then see the error happen when generating code:

> let _=();;
Microsoft (R) Build Engine version 16.7.0-preview-20310-07+ee1c9fd0c for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
C:\Users\codec\AppData\Local\Temp\nuget\10664--f16bc33b-68ac-44ec-9a70-21930c58e389\Project.fsproj : error NU1101: Unable to find package FSharp.DoTheWrongThing. No packages exist with this id in source(s): Microsoft Visual Studio Offline Packages, nuget.org
  Failed to restore C:\Users\codec\AppData\Local\Temp\nuget\10664--f16bc33b-68ac-44ec-9a70-21930c58e389\Project.fsproj (in 1.02 sec).
>

This PR, makes resolution and error reporting eager.

@cartermp
Copy link
Contributor

cartermp commented Jul 9, 2020

fixes #9270

Does this also address #9540 ?

@jonsequitur
Copy link
Contributor

Is there a test to demonstrate this behavior change?

@KevinRansom
Copy link
Contributor Author

KevinRansom commented Jul 9, 2020

@cartermp yes. Although doesn't handle the #i thats a different work item.
@jonsequitur not yet.

@smoothdeveloper
Copy link
Contributor

@KevinRansom I believe this is going to impact paket integration, IIUC it commits each line as soon as they come, which will trigger restore more than once, with potentially conflicting dependencies (when 2 packages are added with transitive dependencies).

The fact that the lines were only committed after encountering ;; or some actual code to validate was probably not an afterthought.

@KevinRansom
Copy link
Contributor Author

@smoothdeveloper , this change does indeed resolve every line, which is not the intent. The intent is to resolve once per commit. More work to do.

@KevinRansom KevinRansom requested review from brettfo and cartermp July 14, 2020 18:45
@KevinRansom KevinRansom merged commit 16d9f11 into dotnet:master Jul 15, 2020
@KevinRansom KevinRansom deleted the eagerpackages branch August 19, 2020 20:22
nosami pushed a commit to xamarin/visualfsharp that referenced this pull request Feb 23, 2021
* Couple of test cases

* Eager packages

* Update fsi.fs

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants