Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Paket thinks things have changed #3218

Closed
haf opened this issue May 23, 2018 · 8 comments
Closed

Paket thinks things have changed #3218

haf opened this issue May 23, 2018 · 8 comments

Comments

@haf
Copy link
Member

haf commented May 23, 2018 •
edited
Loading

Description

I upgraded a few libs in Logary, 'paket update' and then 'paket install' which got:

Performance:
 - Resolver: 11 seconds (1 runs)
    - Runtime: 1 second
    - Blocked (retrieving package details): 10 seconds (167 times)
    - Not Blocked (retrieving package details): 30 times
    - Not Blocked (retrieving package versions): 3 times
 - Disk IO: 208 milliseconds
 - Average Request Time: 82 milliseconds
 - Number of Requests: 183
 - Runtime: 22 seconds
$ $_
0

Then ./build.sh yields a lot of output like:

  Paket version 5.166.0
  paket.dependencies and paket.lock are out of sync in /Users/h/dev/logibit/logary.
  Please run 'paket install' or 'paket update' to recompute the paket.lock file.
  Changes were detected for Main/Expecto
      - SettingsChanged
  Changes were detected for Main/Expecto.FsCheck
      - SettingsChanged
  Changes were detected for Main/Expecto.Hopac
      - SettingsChanged

But running paket install does nothing.

I then ran paket update which is not what I want (because I don't want to update any nugets), and this delta appeared in paket.lock:

diff --git a/paket.lock b/paket.lock
index 7673efe3..17d034a7 100644
--- a/paket.lock
    b/paket.lock
@@ -2122,12  2122,12 @@ NUGET
       System.Runtime (>= 4.3) - restriction: || (&& (== net461) (>= dnxcore50)) (&& (== net461) (< net45)) (== netcoreapp2.0) (== netstandard2.0)
       System.Text.Encoding (>= 4.3) - restriction: || (&& (== net461) (>= dnxcore50)) (&& (== net461) (< net45)) (== netcoreapp2.0) (== netstandard2.0)
     System.Text.RegularExpressions (4.3) - restriction: || (&& (== net461) (< net451) (>= netstandard1.5)) (== netcoreapp2.0) (== netstandard2.0)
-      System.Collections (>= 4.3) - restriction: || (&& (== net461) (== netcoreapp2.0)) (&& (== net461) (>= dnxcore50)) (&& (== net461) (< net45) (>= netstandard1.6)) (&& (== netcoreapp2.0) (>= dnxcore50)) (&& (== netcoreapp2.0) (< netcoreapp1.1)) (== netstandard2.0)
-      System.Globalization (>= 4.3) - restriction: || (&& (== net461) (== netcoreapp2.0)) (&& (== net461) (>= dnxcore50)) (&& (== net461) (< net45) (>= netstandard1.6)) (&& (== netcoreapp2.0) (>= dnxcore50)) (&& (== netcoreapp2.0) (< netcoreapp1.1)) (== netstandard2.0)
-      System.Resources.ResourceManager (>= 4.3) - restriction: || (&& (== net461) (== netcoreapp2.0)) (&& (== net461) (>= dnxcore50)) (&& (== net461) (< net45) (>= netstandard1.6)) (&& (== netcoreapp2.0) (>= dnxcore50)) (&& (== netcoreapp2.0) (< netcoreapp1.1)) (== netstandard2.0)
       System.Collections (>= 4.3) - restriction: || (&& (== net461) (>= dnxcore50)) (&& (== net461) (< net45) (>= netstandard1.6)) (&& (== netcoreapp2.0) (>= dnxcore50)) (&& (== netcoreapp2.0) (< netcoreapp1.1)) (== netstandard2.0)
       System.Globalization (>= 4.3) - restriction: || (&& (== net461) (>= dnxcore50)) (&& (== net461) (< net45) (>= netstandard1.6)) (&& (== netcoreapp2.0) (>= dnxcore50)) (&& (== netcoreapp2.0) (< netcoreapp1.1)) (== netstandard2.0)
       System.Resources.ResourceManager (>= 4.3) - restriction: || (&& (== net461) (>= dnxcore50)) (&& (== net461) (< net45) (>= netstandard1.6)) (&& (== netcoreapp2.0) (>= dnxcore50)) (&& (== netcoreapp2.0) (< netcoreapp1.1)) (== netstandard2.0)
       System.Runtime (>= 4.3) - restriction: || (&& (== net461) (>= dnxcore50)) (&& (== net461) (< net45)) (&& (== net461) (>= netcoreapp1.1)) (== netcoreapp2.0) (== netstandard2.0)
-      System.Runtime.Extensions (>= 4.3) - restriction: || (&& (== net461) (== netcoreapp2.0)) (&& (== net461) (>= dnxcore50)) (&& (== net461) (< net45) (>= netstandard1.6)) (&& (== netcoreapp2.0) (>= dnxcore50)) (&& (== netcoreapp2.0) (< netcoreapp1.1)) (== netstandard2.0)
-      System.Threading (>= 4.3) - restriction: || (&& (== net461) (== netcoreapp2.0)) (&& (== net461) (>= dnxcore50)) (&& (== net461) (< net45) (>= netstandard1.6)) (&& (== netcoreapp2.0) (>= dnxcore50)) (&& (== netcoreapp2.0) (< netcoreapp1.1)) (== netstandard2.0)
       System.Runtime.Extensions (>= 4.3) - restriction: || (&& (== net461) (>= dnxcore50)) (&& (== net461) (< net45) (>= netstandard1.6)) (&& (== netcoreapp2.0) (>= dnxcore50)) (&& (== netcoreapp2.0) (< netcoreapp1.1)) (== netstandard2.0)
       System.Threading (>= 4.3) - restriction: || (&& (== net461) (>= dnxcore50)) (&& (== net461) (< net45) (>= netstandard1.6)) (&& (== netcoreapp2.0) (>= dnxcore50)) (&& (== netcoreapp2.0) (< netcoreapp1.1)) (== netstandard2.0)
     System.Threading (4.3) - restriction: || (&& (== net461) (>= dnxcore50) (>= netstandard1.5)) (&& (== net461) (< net45) (>= netstandard1.6)) (&& (== net461) (< net451) (>= netstandard1.5)) (== netcoreapp2.0) (== netstandard2.0)
       System.Runtime (>= 4.3) - restriction: || (&& (== net461) (>= dnxcore50)) (&& (== net461) (< net45)) (== netcoreapp2.0) (== netstandard2.0)
       System.Threading.Tasks (>= 4.3) - restriction: || (&& (== net461) (>= dnxcore50)) (&& (== net461) (< net45)) (== netcoreapp2.0) (== netstandard2.0)

After letting paket have its way with the lockfile, paket still thinks something is amiss and output the warning while building, so it did not in fact solve anything.

These steps can be done on the parent commit of causiq/logary@d3ce90e

Expected behavior

Following the output's suggestion, paket install, should work.

Also, why paket keeps changing the set of system.* libraries and their constraints I have no idea of, since I haven't changed my compile targets.

Actual behavior

A lot of frequent churn in System.* packages for no apparent reason.

Known workarounds

None
@haf
Copy link
Member Author

haf commented Jun 7, 2018

Another repro: checkout logary at 42aa88966a826a9d640483c3c725a51ccf5c2b0f, run mono .paket/paket.exe update Google.Cloud.Logging.V2 && ./build.sh to reproduce:

paket.dependencies and paket.lock are out of sync in /Users/h/dev/logibit/logary.
Please run 'paket install' or 'paket update' to recompute the paket.lock file.
Changes were detected for Main/Expecto
    - SettingsChanged
Changes were detected for Main/Expecto.FsCheck
    - SettingsChanged
Changes were detected for Main/Expecto.Hopac
    - SettingsChanged

screen shot 2018-06-07 at 21 24 48

Also, if you run mono .paket/paket.exe update just about everything breaks.

@inosik
Copy link
Contributor

inosik commented Jun 8, 2018

Happens on plain paket restore after cloning as well:

$ paket restore --project src/Logary/Logary.fsproj 
Paket version 5.172.0
paket.dependencies and paket.lock are out of sync in /Users/ilja/Projects/logary.
Please run 'paket install' or 'paket update' to recompute the paket.lock file.
Changes were detected for Main/Expecto
    - SettingsChanged
Changes were detected for Main/Expecto.FsCheck
    - SettingsChanged
Changes were detected for Main/Expecto.Hopac
    - SettingsChanged
Starting restore process.
Performance:
 - Disk IO: 20 milliseconds
 - Runtime: 3 seconds

@inosik
Copy link
Contributor

inosik commented Jun 9, 2018

Looks like the generate_load_scripts attribute in paket.lock on these three packages is causing this. I guess it used to be set in paket.dependencies on the Expecto-packages and was changed to be a group setting.

@forki
Copy link
Member

forki commented Jun 11, 2018

after running "paket update" everything is fine

@haf
Copy link
Member Author

haf commented Jun 11, 2018

Not for me:

screen shot 2018-06-11 at 10 17 44

@forki
Copy link
Member

forki commented Jun 11, 2018

can you please check the lock file? the generate_load_script settings should be gone after that

@forki
Copy link
Member

forki commented Jun 11, 2018

ok scratch that. need to investigate further

@forki forki closed this as completed in d89c162 Jun 11, 2018
@forki
Copy link
Member

forki commented Jun 11, 2018

Restore should behave fine now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@forki @haf @inosik