FAKE 5 doesn't install new packages

[inosik]

Description

After adding a new package to the dependencies of my script, FAKE 5 doesn't install the new package.

Repro steps

1. Create this script:

   #r "paket:
   nuget Fake.Core.Target prerelease"
   #load ".fake/build.fsx/intellisense.fsx"
   open Fake.Core
   Target.Create "Default" ignore
   Target.RunOrDefault "Default"

2. Run FAKE

3. Make this change:

   #r "paket:
   -nuget Fake.Core.Target prerelease"
   +nuget Fake.Core.Target prerelease
   +nuget Fake.Core.Globbing prerelease"
   #load ".fake/build.fsx/intellisense.fsx"

4. Run FAKE again

Expected behavior

FAKE should resolve and install the new package.

Actual behavior

The package is only added to .fake/build.fsx/paket.dependencies. It is not added to build.fsx.lock, .fake/build.fsx/paket.lock or .fake/build.fsx/intellisense.fsx. Using anything from that package causes a compilation error.

Known workarounds

• Manually install the new package and copy the lock file:

  pushd .fake/build.fsx/
  paket install
  popd
  cp .fake/build.fsx/paket.lock build.fsx.lock

• Clean everything and run FAKE again:

  rm -r .fake/
  rm build.fsx.lock
  fake run build.fsx

Related information

• Operating system: Windows 10
• FAKE version: 5.0.0-beta014 (fake package from Chocolatey)
• .NET Runtime, CoreCLR or Mono Version: .NET Core SDK 2.1.4

[matthid]

Currently (though arguably not very user friendly) this is by design. All you need to do is delete build.fsx.lock this is documented.

[inosik]

this is documented.

You're right, I've read this on the Getting Started page, but somehow ignored it 😄

Is this going to change at some point? Especially now, with every bit in its own package, I for my part will probably add packages very often while moving to FAKE 5.

BTW, how will we know if a package has an update? Is build.fsx.lock even supposed to be commited?

[matthid]

BTW, how will we know if a package has an update?

Good question, you have suggestions for that? Should we check while the script is running and print a warning at the end?

Is build.fsx.lock even supposed to be commited?

Yes to keep your build stable you might want to consider that. One idea that still is in my mind is to version some modules independently or do breaking changes in them independently. This means some of them might be bumped into a new major release. Currently in the beta-phase it is quite convenient to release everything (it might even stay that way I don't know yet)

I for my part will probably add packages very often while moving to FAKE 5.

yes, maybe we need a command for that? fake update? Initially I thought about something like fake paket update and being able to do paket commands via fake paket ... however I'm not sure that works well.

All in all that is some thinking that crossed my mind, suggestions are welcome :)

[inosik]

Looks like other build systems have a command or even special plugins for that. In FAKE we could simply reuse paket outdated.

One idea that still is in my mind is to version some modules independently or do breaking changes in them independently.

I actually like that we now have modules/packages for the several tools. But I wonder if it's necessary to extract the "core" functionality, like targets and globbing, to their own packages.

But back to the original issue again, I think it would be nice if FAKE could detect changes in the dependencies and would install them automatically. Paket prints a warning if paket.dependencies and paket.lock don't match, right? Can we reuse this?

[matthid]

But I wonder if it's necessary to extract the "core" functionality, like targets and globbing, to their own packages.

Yes merging some modules is an option as well. Something like Fake.CoreLib which would contain some common stuff.
The Fake.Core.Target module however will probably not be part of it. I'd like to keep that separate to enable external packages with new syntax (something for FAKE 6).

Paket prints a warning if paket.dependencies and paket.lock don't match, right? Can we reuse this?

Yes probably, need to check why that warning is not printing already ...

[vanceism7]

I think atleast a run-opt would be useful to make this process a little simpler. A switch like -u/--update I think would be sufficient. So you could do stuff like fake run -u and this would delete the lock file and re-download dependencies

[matthid]

In the mean time we had two other reports of this on gitter. One solution that crossed my mind is (in order to not hurt performance) to detect the compiler errors FS0039 (<> not defined) and FS0043 (<> does not support operator) and hint the user into trying to paket install or deleting <script>.lock. We can do a costly up-to-date check at this place if needed.

[vanceism7]

Yea, since deleting the lock file is by design, I think hinting is probably the best solution here. So users know that this is not some legitimate error in their script but rather just standard fake usage

[matthid]

Now we have:

--- test.unchanged.fsx  2018-05-20 23:33:47.130693100 +0200
+++ test.fsx    2018-05-20 23:35:13.849907000 +0200
@@ -1,7 +1,13 @@
 #r "paket:
-nuget Fake.Core.Target prerelease"
+nuget Fake.Core.Target prerelease
+nuget Fake.IO.FileSystem prerelease"
 #load ".fake/test.fsx/intellisense.fsx"

 open Fake.Core
+open Fake.IO
+
+!! "Some*.glob"
+    |> Seq.iter (printfn "%s")
+
 Target.create "Default" ignore
 Target.runOrDefault "Default"

Leads to

[matthid]

Therefore I consider this closed with rc015 (which is on staging in a couple minutes) please feel free to leave feedback.