Emit fsx issue124 #303

rneatherway · 2014-10-28T15:23:48Z

Not to be merged yet, needs tidying.

forki · 2014-10-28T15:37:51Z

src/Paket.Core/Paket.Core.fsproj

@@ -9,7 +9,7 @@
    <OutputType>Library</OutputType>
    <RootNamespace>Paket</RootNamespace>
    <AssemblyName>Paket.Core</AssemblyName>
-    <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
+    <TargetFrameworkVersion>v4.5</TargetFrameworkVersion>


We need to link against the latest MSBuild DLLs to allow project files with ToolsVersion 12.0 to work. I think therefore that we need to be .NET 4.5. Is that a problem?

mhm seems I don't understand the whole approach.

Can you write a small abstract of what you are doing?

2014-10-28 16:57 GMT+01:00 Robin Neatherway notifications@github.com:

In src/Paket.Core/Paket.Core.fsproj:

@@ -9,7 +9,7 @@
Library
Paket
Paket.Core

v4.0

v4.5

We need to link against the latest MSBuild DLLs to allow project files
with ToolsVersion 12.0 to work. I think therefore that we need to be .NET
4.5. Is that a problem?

—
Reply to this email directly or view it on GitHub
https://github.com/fsprojects/Paket/pull/303/files#r19480690.

rneatherway · 2014-10-28T16:15:41Z

Description of functionality:

The entry point is EmitFsx.PrintFsx. This calls into two other modules:

ProjectParser: this module contains functionality we recently added to FSharp.Compiler.Service. I assumed you wouldn't want to take a dependency on FCS just for this so I extracted the relevant portion and include it here. It uses the MSBuild API to find all the fully resolved references that a given project depends on. This makes sure that any Conditions or similar MSBuild features are obeyed exactly as they would be during the actual build of the project, and the correct references are used.
DependencyOrdering: this module accepts the list of fully resolved references and performs a topological sort on and then returns them in dependency order.

PrintFsx then prints out the references. In the finished version of this PR, this would be written to a script file rather than just printed to the screen.

forki · 2014-10-28T16:20:15Z

Ah Ok thanks for writing this down.

Now I have the next question. Why are you analyzing the project?
We can compute an install model from the paket.references and paket.lock
file. In some projects like FsLab we don't even have a project.
On Oct 28, 2014 5:15 PM, "Robin Neatherway" notifications@github.com
wrote:

Description of functionality:

The entry point is EmitFsx.PrintFsx. This calls into two other modules:

ProjectParser: this module contains functionality we recently added to
FSharp.Compiler.Service. I assumed you wouldn't want to take a dependency
on FCS just for this so I extracted the relevant portion and include it
here. It uses the MSBuild API to find all the fully resolved references
that a given project depends on. This makes sure that any Conditions or
similar MSBuild features are obeyed exactly as they would be during the
actual build of the project, and the correct references are used.
2.

DependencyOrdering: this module accepts the list of fully resolved
references and performs a topological sort on and then returns them in
dependency order.

PrintFsx then prints out the references. In the finished version of this
PR, this would be written to a script file rather than just printed to the
screen.

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

rneatherway · 2014-10-28T16:34:04Z

I am glad that helped.

A project may depend on other projects and assemblies in the GAC, which Paket would not know about. FSI still needs to be told about these assemblies though.

For example, if Project A depends on Project B, System.Xml and Ionic.Zip, then Paket would only know about the last dependency (as far as I understand it). However, to use Project A in FSI, we would want a script file something like:

#r "/usr/lib/mono/gac/System.Xml/4.0.0.0__b77a5c561934e089/System.Xml.dll"
#r "packages/lib/net40/Ionic.Zip.dll"
#r "bin/ProjectB.dll"
#r "bin/ProjectA.dll"

(paths will of course differ on different systems)

This script file can in turn be included with a #load as the first line of any other script file working with this project.

forki · 2014-10-28T16:40:15Z

We actually know about framework reference assemblies if they are listed in
the nuspec.
I don't see why we need to ask MSBuild.
On Oct 28, 2014 5:34 PM, "Robin Neatherway" notifications@github.com
wrote:

I am glad that helped.

A project may depend on other projects and assemblies in the GAC, which
Paket would not know about. FSI still needs to be told about these
assemblies though.

For example, if Project A depends on Project B, System.Xml and Ionic.Zip,
then Paket would only know about the last dependency (as far as I
understand it). However, to use Project A in FSI, we would want a script
file something like:

#r "/usr/lib/mono/gac/System.Xml/4.0.0.0__b77a5c561934e089/System.Xml.dll"
#r "packages/lib/net40/Ionic.Zip.dll"
#r "bin/ProjectB.dll"
#r "bin/ProjectA.dll"

(paths will of course differ on different systems)

This script file can in turn be included with a #load as the first line
of any other script file working with this project.

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

forki · 2014-10-28T16:42:30Z

I thought we are looking for a way to generate fsx import statements based
on paket.lock and paket.references.
On Oct 28, 2014 5:40 PM, "Steffen Forkmann" sforkmann@gmail.com wrote:

We actually know about framework reference assemblies if they are listed
in the nuspec.
I don't see why we need to ask MSBuild.
On Oct 28, 2014 5:34 PM, "Robin Neatherway" notifications@github.com
wrote:

I am glad that helped.

A project may depend on other projects and assemblies in the GAC, which
Paket would not know about. FSI still needs to be told about these
assemblies though.

For example, if Project A depends on Project B, System.Xml and Ionic.Zip,
then Paket would only know about the last dependency (as far as I
understand it). However, to use Project A in FSI, we would want a script
file something like:

#r "/usr/lib/mono/gac/System.Xml/4.0.0.0__b77a5c561934e089/System.Xml.dll"
#r "packages/lib/net40/Ionic.Zip.dll"
#r "bin/ProjectB.dll"
#r "bin/ProjectA.dll"

(paths will of course differ on different systems)

This script file can in turn be included with a #load as the first line
of any other script file working with this project.

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

rneatherway · 2014-10-28T16:50:39Z

Ah, now I don't understand. When you say nuspec file, are you talking about the nuspec file for a particular nuget package that is in paket.lock or paket.references?

As far as I can see, Paket's knowledge only extends to packaged dependencies, and so we have to go to the MSBuild project files to get the full picture (other project references, GAC references etc). I may be wrong on this though.

If we generate an fsx import script only with Paket's knowledge (as I understand it), then it will not be complete with respect to a given project. A user would need to add the other references manually before they could interact with the project.

For example, to play with Paket.Core in FSI you need a few DLLs:

#r @"/home/scratch/local/lib/mono/4.5/System.Core.dll"
#r @"/home/scratch/local/lib/mono/4.5/System.Numerics.dll"
#r @"../../packages/FSharp.Core.Microsoft.Signed/lib/net45/FSharp.Core.dll"
#r @"/home/scratch/local/lib/mono/4.5/System.Data.dll"
#r @"/home/scratch/local/lib/mono/4.5/System.Xml.Linq.dll"
#r @"/home/scratch/local/lib/mono/4.5/FSharp.Data.TypeProviders.dll"
#r @"../../packages/DotNetZip/lib/net20/Ionic.Zip.dll"
#r @"/home/scratch/local/lib/mono/xbuild/12.0/bin/Microsoft.Build.Framework.dll"
#r @"/home/scratch/local/lib/mono/xbuild/12.0/bin/Microsoft.Build.dll"
#r @"/home/scratch/local/lib/mono/xbuild/12.0/bin/Microsoft.Build.Utilities.v12.0.dll"
#r @"/home/scratch/local/lib/mono/xbuild/12.0/bin/Microsoft.Build.Engine.dll"
#r @"/home/scratch/local/lib/mono/xbuild/12.0/bin/Microsoft.Build.Tasks.v12.0.dll"
#r @"../../packages/Newtonsoft.Json/lib/net45/Newtonsoft.Json.dll"
#r @"/auto/users/robnea/dev/Paket2/src/Paket.Core/../../bin/Paket.Core.dll"
#r @"/home/scratch/local/lib/mono/4.5/System.Data.Linq.dll"

Obviously the MSbuild DLLs are because of this PR.

forki · 2014-10-28T17:05:44Z

yes exactly.

But that wasn't what we were looking for, right?
At least not was I was looking for. My use case is much simpler.
I dont want to interact with a project (and the project "local"
dependencies).

I my use case there is no project. Everything is on nuget.

2014-10-28 17:50 GMT+01:00 Robin Neatherway notifications@github.com:

Ah, now I don't understand. When you say nuspec file, are you talking
about the nuspec file for a particular nuget package that is in paket.lock
or paket.references?

As far as I can see, Paket's knowledge only extends to packaged
dependencies, and so we have to go to the MSBuild project files to get the
full picture (other project references, GAC references etc). I may be wrong
on this though.

If we generate an fsx import script only with Paket's knowledge (as I
understand it), then it will not be complete with respect to a given
project. A user would need to add the other references manually before they
could interact with the project.

For example, to play with Paket.Core in FSI you need a few DLLs:

#r @"/home/scratch/local/lib/mono/4.5/System.Core.dll"
#r @"/home/scratch/local/lib/mono/4.5/System.Numerics.dll"
#r @"../../packages/FSharp.Core.Microsoft.Signed/lib/net45/FSharp.Core.dll"
#r @"/home/scratch/local/lib/mono/4.5/System.Data.dll"
#r @"/home/scratch/local/lib/mono/4.5/System.Xml.Linq.dll"
#r @"/home/scratch/local/lib/mono/4.5/FSharp.Data.TypeProviders.dll"
#r @"../../packages/DotNetZip/lib/net20/Ionic.Zip.dll"
#r @"/home/scratch/local/lib/mono/xbuild/12.0/bin/Microsoft.Build.Framework.dll"
#r @"/home/scratch/local/lib/mono/xbuild/12.0/bin/Microsoft.Build.dll"
#r @"/home/scratch/local/lib/mono/xbuild/12.0/bin/Microsoft.Build.Utilities.v12.0.dll"
#r @"/home/scratch/local/lib/mono/xbuild/12.0/bin/Microsoft.Build.Engine.dll"
#r @"/home/scratch/local/lib/mono/xbuild/12.0/bin/Microsoft.Build.Tasks.v12.0.dll"
#r @"../../packages/Newtonsoft.Json/lib/net45/Newtonsoft.Json.dll"
#r @"/auto/users/robnea/dev/Paket2/src/Paket.Core/../../bin/Paket.Core.dll"
#r @"/home/scratch/local/lib/mono/4.5/System.Data.Linq.dll"

Obviously the MSbuild DLLs are because of this PR.

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

forki · 2014-10-28T17:08:20Z

Don't get me wrong. I think your PR is really really useful. But I think it
probably better belongs in fsharpbindings or something like that. Then IDEs
can use it.

For paket I see a much simpler approach.

But I'm not sure if I'm right here.

2014-10-28 18:05 GMT+01:00 Steffen Forkmann sforkmann@gmail.com:

yes exactly.

But that wasn't what we were looking for, right?
At least not was I was looking for. My use case is much simpler.
I dont want to interact with a project (and the project "local"
dependencies).

I my use case there is no project. Everything is on nuget.

2014-10-28 17:50 GMT+01:00 Robin Neatherway notifications@github.com:

Ah, now I don't understand. When you say nuspec file, are you talking
about the nuspec file for a particular nuget package that is in paket.lock
or paket.references?

As far as I can see, Paket's knowledge only extends to packaged
dependencies, and so we have to go to the MSBuild project files to get the
full picture (other project references, GAC references etc). I may be wrong
on this though.

If we generate an fsx import script only with Paket's knowledge (as I
understand it), then it will not be complete with respect to a given
project. A user would need to add the other references manually before they
could interact with the project.

For example, to play with Paket.Core in FSI you need a few DLLs:

#r @"/home/scratch/local/lib/mono/4.5/System.Core.dll"
#r @"/home/scratch/local/lib/mono/4.5/System.Numerics.dll"
#r @"../../packages/FSharp.Core.Microsoft.Signed/lib/net45/FSharp.Core.dll"
#r @"/home/scratch/local/lib/mono/4.5/System.Data.dll"
#r @"/home/scratch/local/lib/mono/4.5/System.Xml.Linq.dll"
#r @"/home/scratch/local/lib/mono/4.5/FSharp.Data.TypeProviders.dll"
#r @"../../packages/DotNetZip/lib/net20/Ionic.Zip.dll"
#r @"/home/scratch/local/lib/mono/xbuild/12.0/bin/Microsoft.Build.Framework.dll"
#r @"/home/scratch/local/lib/mono/xbuild/12.0/bin/Microsoft.Build.dll"
#r @"/home/scratch/local/lib/mono/xbuild/12.0/bin/Microsoft.Build.Utilities.v12.0.dll"
#r @"/home/scratch/local/lib/mono/xbuild/12.0/bin/Microsoft.Build.Engine.dll"
#r @"/home/scratch/local/lib/mono/xbuild/12.0/bin/Microsoft.Build.Tasks.v12.0.dll"
#r @"../../packages/Newtonsoft.Json/lib/net45/Newtonsoft.Json.dll"
#r @"/auto/users/robnea/dev/Paket2/src/Paket.Core/../../bin/Paket.Core.dll"
#r @"/home/scratch/local/lib/mono/4.5/System.Data.Linq.dll"

Obviously the MSbuild DLLs are because of this PR.

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

rneatherway · 2014-10-28T17:11:16Z

Ah, I see. I think we misunderstood each other's use cases. This is what I always had in mind. I think your idea is also useful, but it is a shame that it won't cover this kind of situation.

For dealing with nuget packages, I now see why you mention the nuspec file, but I wonder what you have in mind for choosing the right framework. Working with a fsproj file is useful because it gives you context like that.

forki · 2014-10-28T17:25:32Z

I can see this feature in the F# power tools. Right click on project and it
gives you the script with all the #r statements. I'd love to see this
happen.
On Oct 28, 2014 6:11 PM, "Robin Neatherway" notifications@github.com
wrote:

Ah, I see. I think we misunderstood each other's use cases. This is what I
always had in mind. I think your idea is also useful, but it is a shame
that it won't cover this kind of situation.

For dealing with nuget packages, I now see why you mention the nuspec
file, but I wonder what you have in mind for choosing the right framework.
Working with a fsproj file is useful because it gives you context like that.

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

rneatherway · 2014-10-28T17:46:04Z

Yes, this is perhaps more appropriate. Didn't VS add some capability like this, copy references or something?

I really like Paket, as it is command line and decoupled from VS, it looks good for Mono users too. That's why I was looking to add this here. Perhaps it would go better straight into FSI.

rneatherway · 2014-10-29T11:33:07Z

I checked and VS2013 lets you send references to FSI, but not create a script file.

First cut of semi-working functionality. To be tidied

34f380e

rneatherway mentioned this pull request Oct 28, 2014

Make "Get package" available in REPL #124

Closed

forki reviewed Oct 28, 2014
View reviewed changes

rneatherway closed this Oct 28, 2014

rneatherway mentioned this pull request Mar 10, 2015

Paket should create a package load script #677

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Emit fsx issue124 #303

Emit fsx issue124 #303

rneatherway commented Oct 28, 2014

forki Oct 28, 2014

rneatherway Oct 28, 2014

forki Oct 28, 2014

rneatherway commented Oct 28, 2014

forki commented Oct 28, 2014

rneatherway commented Oct 28, 2014

forki commented Oct 28, 2014

forki commented Oct 28, 2014

rneatherway commented Oct 28, 2014

forki commented Oct 28, 2014

forki commented Oct 28, 2014

rneatherway commented Oct 28, 2014

forki commented Oct 28, 2014

rneatherway commented Oct 28, 2014

rneatherway commented Oct 29, 2014

Emit fsx issue124 #303

Emit fsx issue124 #303

Conversation

rneatherway commented Oct 28, 2014

forki Oct 28, 2014

Choose a reason for hiding this comment

rneatherway Oct 28, 2014

Choose a reason for hiding this comment

forki Oct 28, 2014

Choose a reason for hiding this comment

rneatherway commented Oct 28, 2014

forki commented Oct 28, 2014

rneatherway commented Oct 28, 2014

forki commented Oct 28, 2014

forki commented Oct 28, 2014

rneatherway commented Oct 28, 2014

forki commented Oct 28, 2014

forki commented Oct 28, 2014

rneatherway commented Oct 28, 2014

forki commented Oct 28, 2014

rneatherway commented Oct 28, 2014

rneatherway commented Oct 29, 2014