Fix 2222 - improve output of the outdated warning and fix underlying bug by matthid · Pull Request #2223 · fsprojects/Paket

matthid · 2017-04-09T14:20:17Z

fixes both issues in #2222.

Before

paket.dependencies and paket.lock are out of sync in C:\PROJ\FAKE.
Please run 'paket install' or 'paket update' to recompute the paket.lock file.

After

paket.dependencies and paket.lock are out of sync in C:\PROJ\FAKE.
Please run 'paket install' or 'paket update' to recompute the paket.lock file.
Changes [RestrictionsChanged] were detected in netcore/FSharp.Compiler.Service
Changes [RestrictionsChanged] were detected in netcore/FSharp.Core
Changes [RestrictionsChanged] were detected in netcore/Libuv
Changes [RestrictionsChanged] were detected in netcore/Microsoft.CodeAnalysis.Common
Changes [RestrictionsChanged] were detected in netcore/Microsoft.CodeAnalysis.CSharp
Changes [RestrictionsChanged] were detected in netcore/Microsoft.CodeAnalysis.VisualBasic
Changes [RestrictionsChanged] were detected in netcore/Microsoft.CSharp
Changes [RestrictionsChanged] were detected in netcore/Microsoft.DiaSymReader
Changes [RestrictionsChanged] were detected in netcore/Microsoft.DiaSymReader.PortablePdb
Changes [RestrictionsChanged] were detected in netcore/Microsoft.NETCore.App
Changes [RestrictionsChanged] were detected in netcore/Microsoft.NETCore.DotNetHost
Changes [RestrictionsChanged] were detected in netcore/Microsoft.NETCore.DotNetHostPolicy
Changes [RestrictionsChanged] were detected in netcore/Microsoft.NETCore.DotNetHostResolver
Changes [RestrictionsChanged] were detected in netcore/Microsoft.NETCore.Jit
Changes [RestrictionsChan...

…output.

matthid · 2017-04-09T15:06:00Z

apparently the problem was that paket could not properly parse netcore10 (which it wrote itself).

…we fail whenever they introduce something.

matthid · 2017-04-09T15:55:35Z

Lets see what the CI has to say :)

… behavior/tests)

matthid · 2017-04-09T16:06:25Z

    let rec step (stage:Stage) (stackpack:StackPack) compatibleVersions (flags:StepFlags) =

-        let fuseConflicts currentConflict priorConflictSteps =
+        let inline fuseConflicts currentConflict priorConflictSteps =


@cloudRoutine Is this OK? This prevents a stack-overflow I had when debugging (compiling in DEBUG mode)

interesting. probably just because the stack size was halved due to inlining. but I'm fine with that!

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.

matthid · 2017-04-09T16:11:27Z

-                | "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)


Note: This is in fact cleanup as we have the netcoreapp -> netcore alias defined above.

matthid · 2017-04-09T16:17:31Z

        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())


Generating a really nice output is left as an exercise to the reader :)

yeah we can iterate on that

matthid · 2017-04-09T16:29:34Z

OK This is ready. The AppVeyor error is unrelated and on the master branch as well.

forki · 2017-04-09T16:39:03Z

    <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>


I wished this would be in different file so that we could gitignore.

I can remove that change if you want.

Maybe after @Krzysztof-Cieslak brings the toml file ;)

no it's fine. It's more a general observation. I'm really annoyed about that part of fsproj

yeah not sure if MSbuild 15 is better in that regard. but VS can't read it anyways ;-)

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?)

forki · 2017-04-09T16:39:45Z

Good work! Thanks a lot

matthid · 2017-04-09T16:49:56Z

+                    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


@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...

Good thanks for the warning.

Maybe I should revert the change, push a bug fix version with old code and publish this as minor version change?

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...)

doing it anyways. just in case.

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.

matthid · 2017-04-09T17:05:16Z

Finally the warning is gone. As always thanks for merging and releasing so quickly :)

matthid added 2 commits April 9, 2017 16:17

improve output of the outdated warning.

fd07e55

fixes fsprojects#2222 , paket was not able to properly parse its own …

14319bd

…output.

matthid added 4 commits April 9, 2017 17:12

at least log (maybe even fail?) in such edge cases

3d5551a

of course the logging immediatly found another bug...

36a3269

fail directly as this finds bugs... but ignore nuget texts otherwise …

28e98e5

…we fail whenever they introduce something.

update tests

fb3096e

matthid changed the title ~~WIP fix 2222 - improve output of the outdated warning and fix underlying bug~~ Fix 2222 - improve output of the outdated warning and fix underlying bug Apr 9, 2017

apparently the other way around is better (as we don't have to change…

2728bea

… behavior/tests)

matthid commented Apr 9, 2017

View reviewed changes

some cleanup...

6cb4a35

matthid commented Apr 9, 2017

View reviewed changes

matthid mentioned this pull request Apr 9, 2017

paket.dependencies and paket.lock are out of sync in C:\PROJ\FAKE #2222

Closed

forki reviewed Apr 9, 2017

View reviewed changes

forki merged commit 6cb4a35 into fsprojects:master Apr 9, 2017

matthid commented Apr 9, 2017

View reviewed changes

Conversation

matthid commented Apr 9, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

matthid commented Apr 9, 2017

Uh oh!

matthid commented Apr 9, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

matthid Apr 9, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

matthid commented Apr 9, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

matthid Apr 9, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

forki commented Apr 9, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

matthid commented Apr 9, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

matthid commented Apr 9, 2017 •

edited

Loading

matthid Apr 9, 2017 •

edited

Loading

matthid Apr 9, 2017 •

edited

Loading