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?

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?

@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).