Paket should create a package load script

[forki]

From a twitter discussion with @Rickasaurus:

Paket install should create a .fsx script which contains all #r directives to the libraries in a given package. Ths script should also #load the corresponding package load scripts of transitive dependencies.

This would allow us to just #load a package load script in .fsx files and keep references as stable as possible.

[dungpa]

We have a similar feature (Generate references for F# Interactive) in VFPT. A problem is that assemblies sometimes have implicit ordering. You can't get it right without manual intervention. An example is that FParsecCS.dll has to be referenced before FParsec.dll.

[forki]

Interesting. How does this work in fsproj files?

Also: Can we share the code?

[ghost]

I used the feature from VFPT and had those problems with FSharp.Control.Reactive and FParsec also. It seems to me that as long as all assemblies are referenced in dependency order; everything is fine. that is at least what I keep doing manually so far.

There would be 2 cases to consider then

1. dependencies between assemblies from different packages. This is the case for FSharp.Control.Reactive, where the assemblies from the Rx core libraries need to be loaded first. This could possibly be solved by listing all assembly references according to a topological sort of packet.lock.
2. dependencies between assemblies within the same package like for FParsec. I think one can figure out this internal dependency graph using the Assembly class from System.Reflection.
   Then list all assembly references for the package according to a topological sort of the internal dependency graph.

Combing the two could be used to generate a references.fsx that needs no manual adjustment.

Should I try to provide a solution or have I missed something important?

[dungpa]

Sound about right to me.

This project is probably relevant https://github.com/rneatherway/dependency-ordering.

[forki]

@rneatherway interested in helping here?

[rneatherway]

Is this old PR of mine the kind of thing you are talking about? #303

[forki]

ha! sorry for closing that one. seems I didn't understand it at that time.

can we start over and make it great?

[ghost]

@rneatherway are you doing it then again? It seems to me that your dependency-ordering just needs to be fed with the assembly paths and the problem is solved

[rneatherway]

Well, #303 is basically a source-level import of dependency-ordering, which is oriented around being an MSBuild task so it can't just be used as a library. It also includes the FCS technique for resolving assembly references because we won't be operating as an MSBuild task.

I will try rebasing the PR and see what's changed when I get a moment.

[rneatherway]

Just to be clear, we don't currently have access to the fully resolved assembly paths in Paket do we? Because there are two steps required for this:

1. Fully resolve all assembly paths to get actual concrete assemblies
2. Order them correctly

[forki]

nope. and we need to be careful on our dependencies.

[rneatherway]

Yes, that's why I just included the FCS technique as a source file, so that PR didn't include any more dependencies. It does require switching to .NET 4.5 though, would that be OK?

[forki]

Yep I guess that's fair
On Mar 11, 2015 1:28 PM, "Robin Neatherway" notifications@github.com
wrote:

Yes, that's why I just included the FCS technique as a source file, so
that PR didn't include any more dependencies. It does require switching to
.NET 4.5 though, would that be OK?

—
Reply to this email directly or view it on GitHub
#677 (comment).

[dsyme]

Note you can use #I __SOURCE_DIRECTORY to greatly simplify relative #r references in loader scripts. If fake generates these scripts it should use this trick

[rneatherway]

I have rebased my PR and it is at #702. Please comment gently as it is just a proof of concept. It doesn't currently use the __SOURCE_DIRECTORY__ trick, but it could be changed to do so.

[forki]

this generates a load script based on a proj file. I thought we could generate load scripts for packages. But maybe that's not possible!?

[rneatherway]

Hmm, maybe it's actually easier to work with just a package or set of packages actually, because you already know the full paths to the assemblies. But some packages contain multiple versions of the assemblies, which one should we choose?

[dungpa]

@kfrie Thanks for spelling out the details. I've got the issue fixed in VFPT.

[forki]

We could create multiple load scripts and a default one.
On Mar 13, 2015 3:05 PM, "Robin Neatherway" notifications@github.com
wrote:

Hmm, maybe it's actually easier to work with just a package or set of
packages actually, because you already know the full paths to the
assemblies. But some packages contain multiple versions of the assemblies,
which one should we choose?

—
Reply to this email directly or view it on GitHub
#677 (comment).

[rneatherway]

Yes, I'll have a think about it. I may have time next week

[rneatherway]

I think it is actually not completely straightforward because we will have to do the assembly resolution for any assemblies from the GAC and other packages that the current package depends on. I'm afraid I won't have time for this. If someone does go for it, I suggest using the version of dependency-ordering in #702, which is separated a bit from the MSBuild API that the github project under my account uses.

[baronfel]

@forki is this one able to be closed now that @smoothdeveloper and @matthid finished the loading script generator?