New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix 2222 - improve output of the outdated warning and fix underlying bug #2223
Conversation
apparently the problem was that paket could not properly parse |
Lets see what the CI has to say :) |
@@ -651,7 +651,7 @@ let Resolve (getVersionsF, getPackageDetailsF, groupName:GroupName, globalStrate | |||
|
|||
let rec step (stage:Stage) (stackpack:StackPack) compatibleVersions (flags:StepFlags) = | |||
|
|||
let fuseConflicts currentConflict priorConflictSteps = | |||
let inline fuseConflicts currentConflict priorConflictSteps = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cloudRoutine Is this OK? This prevents a stack-overflow I had when debugging (compiling in DEBUG mode)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
interesting. probably just because the stack size was halved due to inlining. but I'm fine with that!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah okey, I thought the thing is now tail recursive but the compiler is not picking it up because of debug mode. Thanks for the clarification.
src/Paket.Core/FrameworkHandling.fs
Outdated
| "netcore10" | "netcoreapp10" -> Some (DotNetCore DotNetCoreVersion.V1_0) | ||
| "netcore11" | "netcoreapp11" -> Some (DotNetCore DotNetCoreVersion.V1_1) | ||
| "netcore10" -> Some (DotNetCore DotNetCoreVersion.V1_0) | ||
| "netcore11" -> Some (DotNetCore DotNetCoreVersion.V1_1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: This is in fact cleanup as we have the netcoreapp -> netcore
alias defined above.
|
||
let checkResponse = if failOnChecks then failwithf else traceWarnfn | ||
if hasAnyChanges then | ||
checkResponse "paket.dependencies and paket.lock are out of sync in %s.%sPlease run 'paket install' or 'paket update' to recompute the paket.lock file." lockFileName.Directory.FullName Environment.NewLine | ||
for (group, package, changes) in nugetChanges do | ||
traceWarnfn "Changes %A were detected in %s/%s" changes (group.ToString()) (package.ToString()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generating a really nice output is left as an exercise to the reader :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah we can iterate on that
OK This is ready. The AppVeyor error is unrelated and on the master branch as well. |
@@ -37,8 +37,8 @@ | |||
<StartWorkingDirectory>D:\temp\coreclrtest</StartWorkingDirectory> | |||
<StartArguments>install</StartArguments> | |||
<StartWorkingDirectory>C:\dev\src\Paket\integrationtests\scenarios\loading-scripts\dependencies-file-flag\temp</StartWorkingDirectory> | |||
<StartArguments>install --createnewbindingfiles</StartArguments> | |||
<StartWorkingDirectory>D:\temp\pakkit2</StartWorkingDirectory> | |||
<StartArguments>install</StartArguments> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wished this would be in different file so that we could gitignore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can remove that change if you want.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe after @Krzysztof-Cieslak brings the toml file ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no it's fine. It's more a general observation. I'm really annoyed about that part of fsproj
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah not sure if MSbuild 15 is better in that regard. but VS can't read it anyways ;-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well maybe we soon use all VSCode with ionide (when the full .net debugger works) and we don't have this problem anymore (because VSCode uses its own json files for debugging?)
Good work! Thanks a lot |
let item = operatorSplit.[3] | ||
match FrameworkDetection.Extract(item) with | ||
| None -> | ||
handleError <| sprintf "Could not parse second framework of between operator '%s'. Try to update or install again or report a paket bug." item |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@forki Just in case I cannot react fast enough and people are experiencing failures tomorrow: We can just set failImmediatly
to false
within the parseRestrictions
function (as first operation, essentially ignoring the parameter). This way paket will log errors instead of failing directly. But more often than not this indicates a bug somewhere...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good thanks for the warning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I should revert the change, push a bug fix version with old code and publish this as minor version change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is a new feature, I have not met a case where this actually triggered wrongly.
I encountered two cases:
- The file was written by paket and can no longer be parsed -> paket bug (another minor increase)
- The file was written by the user (paket.references for example in my test case) -> user error as he entered some invalid value, its just that paket never told him.
All in all I think a patch version is enough as this indeed fixes a bug (one could argue if the additional output is a new feature though...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
doing it anyways. just in case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So if something belongs into a minor release its the logic required to produce the additional output and not this part ;). But that's of IMHO.
Finally the warning is gone. As always thanks for merging and releasing so quickly :) |
fixes both issues in #2222.
Before
After