Share a `paket.dependencies` file between multiple scripts in different directories

MiloszKrajewski commented 5 years ago

fake5.paket.zip

Description

Most likely I'm doing it wrong, I just try to understand how it actually works. I wanted to use paket (explicitly) to get all FAKE5 dependencies. I removed #r "paket: ..." line(s) from .fsx and added all FAKE dependencies to paket.dependencies with in separate group and generate load scripts: (NOTE: it is netcoreapp2.1 now, but i tried many combinations)

group Fake
    storage none
    framework netcoreapp21
    source https://www.nuget.org/api/v2
    generate_load_scripts true
    nuget Fake.Core.Target

From build.fsx i removed #r "paket: ..." and "#load intellisense.fsx" and added my own:

#load "./.paket/load/netcoreapp2.1/Fake/fake.group.fsx"

I understand this is not enough as it blows up with Could not load file or assembly Fake.Core.Target anyway.

Can I make it work this way at all?

Repro steps

Unzip attached project
paket restore
fake build

Expected behavior

Working.

Actual behavior

Could not load file or assembly Fake.Core.Target

Known workarounds

Use #r "paket: ..." approach.

Related information

Operating system: Win10
.NET Runtime, CoreCLR or Mono Version: NET 4.7, NET core 2.2
Version of FAKE (4.X, 5.X): 5.13.2 (Paket.Core: 5.203.2) FakePath: xxx\.fake\.store\fake-cli\5.13.2\fake-cli\5.13.2\tools\netcoreapp2.1\any\Fake.Runtime.dll

matthid commented 5 years ago

Can I make it work this way at all?

No, the short answer is that this is not a supported use case. My question would be why you want to go this low level and potentially break on fake updates or other changes in the ecosystem?

MiloszKrajewski commented 5 years ago

It was a little bit related to my OCD. I have some helpers as .fsx script shared by multiple projects and it was a little cleaner to have them listed in one paket.dependencies than in rely on one build.fsx list them.

As I said, OCD.

matthid commented 5 years ago

Note to be exact: Usung paket groups via paket.dependencies is supported, you can use #r "paket: groupref Build" or the magic // [ FAKE GROUP ] comment I believe this is properly documented.

What is not supported is referencing dlls directly (or using paket load scripts)

matthid commented 5 years ago

Still, If you care elaborating what exactly you want to achieve (if it isn't solved by my last comment) is appreciated

MiloszKrajewski commented 5 years ago

MY case was about having some .fsx shared between multiple project but referencing FAKE assemblies. It would be outside any particular build.fsx root:

Something like that:

/project1
    build.fsx (does NOT reference FAKE assemblies directly, but imports "../shared/tools.fsx")
    paket.dependencies (project related only)
/project2
    build.fsx (does NOT reference FAKE assemblies directly, but imports "../shared/tools.fsx")
    paket.dependencies (project related only)
/shared
    tools.fsx (references FAKE assemblies, through script generated by paket)
    paket.dependencies (FAKE related)

matthid commented 5 years ago

Ok I took a quick look, and I feel like there are two ways to make this "work":

Make sure #load works when the loaded file contains #r "paket: ..."

In this scenario, you would just use

/project1/build.fsx

#load "../shared/tools.fsx"
#load "../shared/.fake/tools.fsx/intellisense.fsx"

open Fake.Core

printfn "test"

In a first step, we wouldn't support multiple #r "paket: " directives but you could "share" one. And fake could make sure to re-use caching where possible, maybe.

Make sure you can somehow point to a paket.dependencies in a different folder.

In this scenario, you would use

/project1/build.fsx

#r "paket: groupref Build"
#r "paket: dependenciesfile ../shared/paket.dependencies"
#load "../shared/.fake/tools.fsx/intellisense.fsx"

open Fake.Core

printfn "test"

Fake would ignore #r "paket:" in #loaded scripts, just like today.

Generally, I'd say 2. is easier to implement. But yes I have not found an easy way to make it work today.

github-actions[bot] commented 4 years ago

There has not been any activity in this issue for the last 3 months so it will be closed in 14 days if there is no activity.

fsprojects / FAKE