2186: Look for Paket executable without ".exe" extension on non-Windows platforms.

[atlemann]

Looking for a file called paket without .exe extension on non-windows platforms before falling back to paket.exe. This is to support Paket bootstrapped in .NET Core "mode".

Fixes #2186

I could not find any tests for this module.

[matthid]

if we already search for it why not use that result but search again?

[atlemann]

True, I was just thinking that it needs to fall back to mono if Paket is full framework. Then it needs to search for paket.exe. I can try to avoid double search before the merge.

[matthid]

We might need to introduce a tryFindToolFolderInSubPath and call that first and retry with the .exe

[atlemann]

I thought about that. I can try that out instead, but what should the fallback be if it can't find any of them?

[matthid]

I'd problably use try* for the first and the other overload for the second call (ie. just use the default paket.exe as we do now)

[matthid]

Thanks for adding support for this scenario!

[atlemann]

Not sure if using Path.GetDirectoryName is ok. I guess creating that FileInfo object and calling .Directory could throw and exception, which would use the default folder instead. What do you think?

[matthid]

Not sure if using Path.GetDirectoryName is ok.

Yes that is ok.

I could not find any tests for this module.

Yes we probably should add some tests to this module or at least for the "new" use-case

[atlemann]

I guess the try-with can be removed if we keep Path.GetDirectoryName. But I'm just wondering if there was a reason FileInfo.Directory was used originally.

Where should a test file be created. And should it be called PaketSpecs.fs?

[matthid]

@atlemann You could for example copy https://github.com/fsharp/FAKE/blob/release/next/src/test/Fake.Core.UnitTests/Fake.DotNet.Cli.fs rename and edit accordingly and add it to either https://github.com/fsharp/FAKE/blob/release/next/src/test/Fake.Core.UnitTests/Fake.Core.UnitTests.fsproj or the integration test project.

You should be able to either run the test via command line (I usually use dotnet run --project src/test/Fake.Core.UnitTest -- or dotnet run --project src/test/Fake.Core.UnitTest -- --run "testgroup/testname" to run a specific test.
I think you can also use visual studio to run them but I'm not sure (we might need to update the adapter, I personally almost never use it).

is that the info you wanted?

I guess the try-with can be removed if we keep Path.GetDirectoryName.

Personally I'm always very nervous when I see with _ -> None so removing is fine by me (we can catch a more specific exception later if needed)

[matthid]

Any reason why that needs to be sequenced (not that I think it would matter)?

[atlemann]

Because they would conflict when run in parallel due to this search pattern in the impl. !! ("./**/" @@ toolname). Maybe there's a better way to do the tests?

[atlemann]

Ops, forgot to remove Focused flag

[matthid]

Because they would conflict when run in parallel due to this search pattern in the impl. !! ("./**/" @@ toolname). Maybe there's a better way to do the tests?

Ah, because you find other results... Yes the "ultimate" solution would be to somehow mock "Environment.CurrentDirectory" but it's fine as it is. Can you add that fact as comment for future reader? Something like // sequenced because otherwise folders conflict with '!! "./**"'

[matthid]

Thanks a lot for taking care of this! Will be part of the next release (will merge once green)

[atlemann]

No problem! You guys are doing all the hard work.