Suggestions for load script generation

@sylvanc and I have been using the amazing package-load-script-generation feature. It’s fantastic

Here are some suggestions for how it can be adjusted

• Always generate the package load scripts by default. They are just too useful to not do it
• Always generate by assuming the latest .NET Framework by default (net462) unless told otherwise.
• Always generate “paket-refs.fsx” (or “paket-refs.csx”) next to paket.dependencies that references all the package loads.
• If there is a non-main group of references then generate paket-build-refs.fsx
• Never generate a #r on FSharp.Core. I think @tpetricek is adding a separate issue on this.

This would make the feature really, really usable. Right now putting things deep in paket-files makes things hard.

thanks don

cc @dungpa

[smoothdeveloper]

The changes have been released in latest paket 4 alpha release:

• files have moved to .paket/load folder
• the include. file name prefix is gone
• when we can assume a default framework, we don’t generate a subfolder with framework name (in practice that mean having framework: single-framework-here in the paket.dependencies file)

[cloudRoutine]

root directory pollution is becoming an increasing problem as every CI, editor, extension, build tool, and their father, mother, sister and brother has decided they must be at the root to work. I wish people would start adopting the convention that all of this could go in /.config/ at root instead.

Let’s not contribute to this issue by default.

@isaacabraham while /paket-files/include-scripts/net46/include.main.group.fsx is definitely onerous wouldn’t something like /load-scripts/main.fsx or /paket-files/load.fsx or /paket-files/load-refs.fsx be easy enough?

As far as discoverability goes, an easy way to let people know where the load script is located

λ» paket generate-load-scripts
Paket version 4.0.0-alpha030
generating scripts for framework net46
+ load script generated @
+ ./load-scripts/main.fsx

is just to tell them where the script was generated

(I’m not clear there is such thing as “highest framework version”, in the context of different platforms).

@smoothdeveloper looking backward I’m not sure how to approach it, but moving forward the netstandard library version compatibility is the way to set this

But I do agree that at the very least the current convention should really be changed (maybe for paket4 so it can be breaking 😈 )

First and foremost why are they called include scripts? It’s not a term that’s used in common F# or .Net parlance, in oth .fsx and .csx files you #load scripts so why not just call it generate-load-scripts?

/paket-files/include-scripts/net46/include.fsharp.compiler.service.fsx

^ why does it need to say include twice?

^ this is already kind of a mess, and as more people start using netcore it’s only going to get worse.

Some conventions that could clean this up would be:

• a specific directory for load scripts like /load-scripts/ at repo root
• don’t put the framework in path of the default scripts generated
• generate the default script by using the lockfile to determine the lowest compatible framework to load the entire group (unless this has some problems I’m overlooking?)
• add the framework that’s being used by default to the print message for the default generated scripts

Loaded group Main, framework - net46

• put the load scripts for each group in /load-scripts/ e.g.

/load-scripts/main.fsx
/load-scripts/group1.fsx
/load-scripts/group2.fsx

• put the load scripts for specific packages in a group in a directory with the same name as that group

/load-scripts/main.fsx
/load-scripts/main/fsharp.compiler.service.fsx
/load-scripts/main/system.buffers.fsx
/load-scripts/main/system.collections.fsx

• print warning messages when some packages in a group can’t have a load script generated for a particular framework
• print warning/error message when no load scripts can be generated for a particular framework
• don’t create a directory for a framework when no load scripts could be generated for it
• when generating load scripts for frameworks other then the default put them in a subdirectory with the framework name in the path following the same convention as the defaults

/load-scripts/net40/main.fsx
/load-scripts/net40/main/fsharp.compiler.service.fsx
/load-scripts/net40/group1.fsx
/load-scripts/net40/group2.fsx