Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lock file should be more legible #123

Closed
bartelink opened this issue Sep 19, 2014 · 22 comments
Closed

Lock file should be more legible #123

bartelink opened this issue Sep 19, 2014 · 22 comments

Comments

@bartelink
Copy link
Member

My lock file has:

NUGET
  remote: http://nuget.org/api/v2
  specs:
    Microsoft.AspNet.WebApi (5.2.2)
      Microsoft.AspNet.WebApi.WebHost (>= 5.2.2, <  5.3.0)
    Microsoft.AspNet.WebApi.Client (5.2.2)
      Newtonsoft.Json (>= 6.0.4)
      Newtonsoft.Json (>= 6.0.4)
      Microsoft.Net.Http (>= 2.2.22)
    Microsoft.AspNet.WebApi.Core (5.2.2)
      Microsoft.AspNet.WebApi.Client (>= 5.2.2)
    Microsoft.AspNet.WebApi.WebHost (5.2.2)
      Microsoft.AspNet.WebApi.Core (>= 5.2.2, <  5.3.0)
    Microsoft.Bcl (1.1.9)
      Microsoft.Bcl.Build (>= 1.0.14)
    Microsoft.Bcl.Build (1.0.21)
    Microsoft.Net.Http (2.2.28)
      Microsoft.Bcl (>= 1.1.9)
      Microsoft.Bcl.Build (>= 1.0.14)
    Newtonsoft.Json (6.0.5)
    Unquote (2.2.2)
    bootstrap (3.2.0)
      jquery (>= 1.9.0)
    hyprlinkr (1.1.1)
      Microsoft.AspNet.WebApi.Core (>= 4.0.20710.0)
    jquery (2.1.1)
    xunit (1.9.2)

STEP 1: Enrich with incoming and outgoing edges
(not shown)

STEP 2: Separate into ones with None outgoing edges vs Some (Q: what is best symbol? want an arrow effect like the pipes I have but dont want to clash with equality operators in version specs ... -> / <- ? Gratuitous unicode symbols? >> / << ? @ReedCopsey :P)

    bootstrap (3.2.0)
      <| jquery (>= 1.9.0)
    hyprlinkr (1.1.1)
      <| Microsoft.AspNet.WebApi.Core (>= 4.0.20710.0)
    Microsoft.AspNet.WebApi (5.2.2)
      <| Microsoft.AspNet.WebApi.WebHost (>= 5.2.2, <  5.3.0)
    Unquote (2.2.2)
    xunit (1.9.2)

    jquery (2.1.1)
       |> bootstrap (>= 1.9.0)  
    Microsoft.Bcl (1.1.9)
      |> Microsoft.Net.Http (>= 1.1.9)
    Microsoft.Bcl.Build (1.0.21)
      |> Microsoft.Bcl (>= 1.0.14)
      |> Microsoft.Net.Http (>= 1.0.14)
    Microsoft.AspNet.WebApi.Client (5.2.2)
      |> Microsoft.AspNet.WebApi.Core (>= 5.2.2)
      <| Newtonsoft.Json (>= 6.0.4)
      <| Newtonsoft.Json (>= 6.0.4)
      <| Microsoft.Net.Http (>= 2.2.22)
    Microsoft.AspNet.WebApi.Core (5.2.2)
      |> hyprlinkr (>= 4.0.20710.0)
      |> Microsoft.AspNet.WebApi.WebHost (>= 5.2.2, <  5.3.0)
      <| Microsoft.AspNet.WebApi.Client (>= 5.2.2)
      <| Microsoft.Net.Http (>= 2.2.22)
    Microsoft.AspNet.WebApi.WebHost (5.2.2)
      |> Microsoft.AspNet.WebApi (>= 5.2.2, <  5.3.0)
      <| Microsoft.AspNet.WebApi.Core (>= 5.2.2, <  5.3.0)
    Microsoft.Net.Http (2.2.28)
      |> Microsoft.AspNet.WebApi.Core (>= 2.2.22)
      <| Microsoft.Bcl (>= 1.1.9)
      <| Microsoft.Bcl.Build (>= 1.0.14)
    Newtonsoft.Json (6.0.5)
      |> Microsoft.AspNet.WebApi.Client (>= 6.0.4)
      |> Microsoft.AspNet.WebApi.Client (>= 6.0.4)

STEP 3: Distill second group:

(as in step 2, nodes with no outgoing edges)

bootstrap (3.2.0)
  <| jquery (>= 1.9.0)
hyprlinkr (1.1.1)
  <| Microsoft.AspNet.WebApi.Core (>= 4.0.20710.0)
Microsoft.AspNet.WebApi (5.2.2)
  <| Microsoft.AspNet.WebApi.WebHost (>= 5.2.2, <  5.3.0)
Unquote (2.2.2)
xunit (1.9.2)

(3A: direct depends from prev group with no path)

jquery (2.1.1)
   |> bootstrap (>= 1.9.0)  
Microsoft.AspNet.WebApi.Core (5.2.2)
  |> hyprlinkr (>= 4.0.20710.0)
  |> Microsoft.AspNet.WebApi.WebHost (>= 5.2.2, <  5.3.0)
  <| Microsoft.AspNet.WebApi.Client (>= 5.2.2)
  <| Microsoft.Net.Http (>= 2.2.22)
Microsoft.AspNet.WebApi.WebHost (5.2.2)
  |> Microsoft.AspNet.WebApi (>= 5.2.2, <  5.3.0)
  <| Microsoft.AspNet.WebApi.Core (>= 5.2.2, <  5.3.0)

(3B: direct depends from prev group with no path)

Microsoft.AspNet.WebApi.Client (5.2.2)
  |> Microsoft.AspNet.WebApi.Core (>= 5.2.2)
  <| Newtonsoft.Json (>= 6.0.4)
  <| Newtonsoft.Json (>= 6.0.4)
  <| Microsoft.Net.Http (>= 2.2.22)
Microsoft.Net.Http (2.2.28)
  |> Microsoft.AspNet.WebApi.Core (>= 2.2.22)
  <| Microsoft.Bcl (>= 1.1.9)
  <| Microsoft.Bcl.Build (>= 1.0.14)

(3C: direct depends from prev group with no path)

Microsoft.Bcl (1.1.9)
  |> Microsoft.Net.Http (>= 1.1.9)
Microsoft.Bcl.Build (1.0.21)
  |> Microsoft.Bcl (>= 1.0.14)
  |> Microsoft.Net.Http (>= 1.0.14)
Newtonsoft.Json (6.0.5)
  |> Microsoft.AspNet.WebApi.Client (>= 6.0.4)
  |> Microsoft.AspNet.WebApi.Client (>= 6.0.4)

Proposal

bootstrap (3.2.0)
  + jquery (>= 1.9.0)
hyprlinkr (1.1.1)
  + Microsoft.AspNet.WebApi.Core (>= 4.0.20710.0)
Microsoft.AspNet.WebApi (5.2.2)
  + Microsoft.AspNet.WebApi.WebHost (>= 5.2.2, <  5.3.0)
Unquote (2.2.2)
xunit (1.9.2)

jquery (2.1.1)
  -> bootstrap (>= 1.9.0)   
Microsoft.AspNet.WebApi.Core (5.2.2)
  + Microsoft.AspNet.WebApi.Client (>= 5.2.2)
  + Microsoft.Net.Http (>= 2.2.22)
  -> hyprlinkr (>= 4.0.20710.0)
  -> Microsoft.AspNet.WebApi.WebHost (>= 5.2.2, <  5.3.0)
Microsoft.AspNet.WebApi.WebHost (5.2.2)
  + Microsoft.AspNet.WebApi.Core (>= 5.2.2, <  5.3.0)
  -> Microsoft.AspNet.WebApi (>= 5.2.2, <  5.3.0)

Microsoft.AspNet.WebApi.Client (5.2.2)
  + Newtonsoft.Json (>= 6.0.4)
  + Newtonsoft.Json (>= 6.0.4)
  + Microsoft.Net.Http (>= 2.2.22)
  -> Microsoft.AspNet.WebApi.Core (>= 5.2.2)
Microsoft.Net.Http (2.2.28)
  + Microsoft.Bcl (>= 1.1.9)
  + Microsoft.Bcl.Build (>= 1.0.14)
  -> Microsoft.AspNet.WebApi.Core (>= 2.2.22)

Microsoft.Bcl (1.1.9)
  -> Microsoft.Net.Http (>= 1.1.9)
Microsoft.Bcl.Build (1.0.21)
  -> Microsoft.Bcl (>= 1.0.14)
  -> Microsoft.Net.Http (>= 1.0.14)
Newtonsoft.Json (6.0.5)
  -> Microsoft.AspNet.WebApi.Client (>= 6.0.4)
  -> Microsoft.AspNet.WebApi.Client (>= 6.0.4)

Design Notes:

  • This format should yield relevant diffs from text based diffing tools over time
  • the paket install process only needs to read unindented lines
  • the -> and + symbols are wide open for discussion. For me the key consideration is wehther whetherthey clash with the comparison symbols in the version specs.
  • I think grouping is important (and the associated blank lines) as
    • we have a graph so nesting won't work but we still want to expose the depth of the dependency relationship
    • sorting only makes sense with items at similar levels in the hierarchy
    • the diffs make more sense when one can see an item switching groups
    • we need to group to be able to surface information that is not obvious from a flat list

Other ideas:

  • The lock file should prob have a child under each top level item detailing the rule that triggered it
  • it's OK if a non paket simplifyd file produces a single flat group - the+ and -> relationships will give clues as to the nature of the relationships (e.g. can see if a component is top level by lack of ->)

Original proposal for posterity / to make comments make sense

    bootstrap (3.2.0)
      jquery (>= 1.9.0)
    hyprlinkr (1.1.1)
      Microsoft.AspNet.WebApi.Core (>= 4.0.20710.0)
    Microsoft.AspNet.WebApi (5.2.2)
      Microsoft.AspNet.WebApi.WebHost (>= 5.2.2, <  5.3.0)
    Unquote (2.2.2)
    xunit (1.9.2)

    Microsoft.AspNet.WebApi.WebHost (5.2.2)
      Microsoft.AspNet.WebApi.Core (>= 5.2.2, <  5.3.0)
    Microsoft.AspNet.WebApi.Core (5.2.2)
      Microsoft.AspNet.WebApi.Client (>= 5.2.2)
    jquery (2.1.1)

    Microsoft.AspNet.WebApi.Client (5.2.2)
      Newtonsoft.Json (>= 6.0.4)
      Newtonsoft.Json (>= 6.0.4)
      Microsoft.Net.Http (>= 2.2.22)

    Microsoft.Net.Http (2.2.28)
      Microsoft.Bcl (>= 1.1.9)
      Microsoft.Bcl.Build (>= 1.0.14)
    Newtonsoft.Json (6.0.5)

    Microsoft.Bcl (1.1.9)
      Microsoft.Bcl.Build (>= 1.0.14)
    Microsoft.Bcl.Build (1.0.21)
@bartelink
Copy link
Member Author

A further example:

    Antlr (3.5.0.2)
    FsWebAddRegistryEntries (0.1.0.0)
    Hyprlinkr (1.1.1)
      Microsoft.AspNet.WebApi.Core (>= 4.0.20710.0)
    Microsoft.AspNet.Mvc (5.0.0)
      Microsoft.AspNet.WebPages (>= 3.0.0)
      Microsoft.AspNet.Razor (>= 3.0.0)
    Microsoft.AspNet.Razor (3.2.2)
    Microsoft.AspNet.Web.Optimization (1.1.2)
      Microsoft.Web.Infrastructure (>= 1.0.0)
      WebGrease (>= 1.5.2)
    Microsoft.AspNet.WebApi (5.2.2)
      Microsoft.AspNet.WebApi.WebHost (>= 5.2.2, <  5.3.0)
    Microsoft.AspNet.WebApi.Client (5.2.2)
      Newtonsoft.Json (>= 6.0.4)
      Newtonsoft.Json (>= 6.0.4)
      Microsoft.Net.Http (>= 2.2.22)
    Microsoft.AspNet.WebApi.Core (5.2.2)
      Microsoft.AspNet.WebApi.Client (>= 5.2.2)
    Microsoft.AspNet.WebApi.WebHost (5.2.2)
      Microsoft.AspNet.WebApi.Core (>= 5.2.2, <  5.3.0)
    Microsoft.AspNet.WebPages (3.2.2)
      Microsoft.Web.Infrastructure (>= 1.0.0.0)
      Microsoft.AspNet.Razor (>= 3.2.2, <  3.3.0)
    Microsoft.Bcl (1.1.9)
      Microsoft.Bcl.Build (>= 1.0.14)
    Microsoft.Bcl.Build (1.0.21)
    Microsoft.Net.Http (2.2.28)
      Microsoft.Bcl (>= 1.1.9)
      Microsoft.Bcl.Build (>= 1.0.14)
    Microsoft.Web.Infrastructure (1.0.0.0)
    Modernizr (2.6.2)
    Newtonsoft.Json (6.0.5)
    Respond (1.3.0)
    Unquote (2.2.2)
    WebGrease (1.6.0)
      Antlr (>= 3.4.1.9004)
      Newtonsoft.Json (>= 5.0.4)
    bootstrap (3.2.0)
      jQuery (>= 1.9.0)
    jQuery (2.1.1)
    xunit (1.9.2)

Should render as:

    bootstrap (3.2.0)
      + jQuery (>= 1.9.0)
    FsWebAddRegistryEntries (0.1.0.0)
    Hyprlinkr (1.1.1)
      + Microsoft.AspNet.WebApi.Core (>= 4.0.20710.0)
    Microsoft.AspNet.Mvc (5.0.0)
      + Microsoft.AspNet.WebPages (>= 3.0.0)
      + Microsoft.AspNet.Razor (>= 3.0.0)
    Microsoft.AspNet.WebApi (5.2.2)
      + Microsoft.AspNet.WebApi.WebHost (>= 5.2.2, <  5.3.0)
    Microsoft.AspNet.Web.Optimization (1.1.2)
      + Microsoft.Web.Infrastructure (>= 1.0.0)
      + WebGrease (>= 1.5.2)
    Modernizr (2.6.2)
    Respond (1.3.0)
    Unquote (2.2.2)
    xunit (1.9.2)

    jQuery (2.1.1)
      -> bootstrap (>= 1.9.0)
    Microsoft.AspNet.Razor (3.2.2)
      -> Microsoft.AspNet.Mvc (>= 3.0.0)
    Microsoft.AspNet.WebApi.Client (5.2.2)
      + Newtonsoft.Json (>= 6.0.4)
      + Newtonsoft.Json (>= 6.0.4)
      + Microsoft.Net.Http (>= 2.2.22)
      -> Microsoft.AspNet.WebApi.Core (>= 5.2.2)
    Microsoft.AspNet.WebApi.Core (5.2.2)
      + Microsoft.AspNet.WebApi.Client (>= 5.2.2)
      -> hyprlinkr (>= 4.0.20710.0)
    Microsoft.AspNet.WebApi.WebHost (5.2.2)
      + Microsoft.AspNet.WebApi.Core (>= 5.2.2, <  5.3.0)
      -> Microsoft.AspNet.WebApi (>= 5.2.2, <  5.3.0)
    Microsoft.AspNet.WebPages (3.2.2)
      + Microsoft.Web.Infrastructure (>= 1.0.0.0)
      + Microsoft.AspNet.Razor (>= 3.2.2, <  3.3.0)
      -> Microsoft.AspNet.Mvc (>= 3.0.0)
    Microsoft.Web.Infrastructure (1.0.0.0)
      -> Microsoft.AspNet.Web.Optimization (>= 1.0.0)
    WebGrease (1.6.0)
      + Antlr (>= 3.4.1.9004)
      + Newtonsoft.Json (>= 5.0.4)
      -> Microsoft.AspNet.Web.Optimization (>= 1.5.2)

    Antlr (3.5.0.2)
      -> WebGrease (>= 3.4.1.9004)
    Microsoft.Net.Http (2.2.28)
      + Microsoft.Bcl (>= 1.1.9)
      + Microsoft.Bcl.Build (>= 1.0.14)
      -> Microsoft.AspNet.WebApi.Client (>= 2.2.22)
    Newtonsoft.Json (6.0.5)
      -> WebGrease (>= 5.0.4)
      -> Microsoft.AspNet.WebApi.Client (>= 6.0.4)
      -> Microsoft.AspNet.WebApi.Client (>= 6.0.4)

    Microsoft.Bcl (1.1.9)
      -> Microsoft.Net.Http (>= 1.1.9)
    Microsoft.Bcl.Build (1.0.21)
      -> Microsoft.Bcl (>= 1.0.14)
      -> Microsoft.Net.Http (>= 1.0.14)

This allowed me to manually shrink my Paket.references to

bootstrap
FsWebAddRegistryEntries
Microsoft.AspNet.Mvc
Microsoft.AspNet.Web.Optimization
Microsoft.AspNet.WebApi
Modernizr
Respond

by looking at the first batch

@forki
Copy link
Member

forki commented Sep 19, 2014

I agree about the sorting. I thought I had this already fixed. Mhm will
investigate and add a regression test.
On Sep 19, 2014 12:24 PM, "bartelink" notifications@github.com wrote:

A further example:

Antlr (3.5.0.2)
FsWebAddRegistryEntries (0.1.0.0)
Hyprlinkr (1.1.1)
  Microsoft.AspNet.WebApi.Core (>= 4.0.20710.0)
Microsoft.AspNet.Mvc (5.0.0)
  Microsoft.AspNet.WebPages (>= 3.0.0)
  Microsoft.AspNet.Razor (>= 3.0.0)
Microsoft.AspNet.Razor (3.2.2)
Microsoft.AspNet.Web.Optimization (1.1.2)
  Microsoft.Web.Infrastructure (>= 1.0.0)
  WebGrease (>= 1.5.2)
Microsoft.AspNet.WebApi (5.2.2)
  Microsoft.AspNet.WebApi.WebHost (>= 5.2.2, <  5.3.0)
Microsoft.AspNet.WebApi.Client (5.2.2)
  Newtonsoft.Json (>= 6.0.4)
  Newtonsoft.Json (>= 6.0.4)
  Microsoft.Net.Http (>= 2.2.22)
Microsoft.AspNet.WebApi.Core (5.2.2)
  Microsoft.AspNet.WebApi.Client (>= 5.2.2)
Microsoft.AspNet.WebApi.WebHost (5.2.2)
  Microsoft.AspNet.WebApi.Core (>= 5.2.2, <  5.3.0)
Microsoft.AspNet.WebPages (3.2.2)
  Microsoft.Web.Infrastructure (>= 1.0.0.0)
  Microsoft.AspNet.Razor (>= 3.2.2, <  3.3.0)
Microsoft.Bcl (1.1.9)
  Microsoft.Bcl.Build (>= 1.0.14)
Microsoft.Bcl.Build (1.0.21)
Microsoft.Net.Http (2.2.28)
  Microsoft.Bcl (>= 1.1.9)
  Microsoft.Bcl.Build (>= 1.0.14)
Microsoft.Web.Infrastructure (1.0.0.0)
Modernizr (2.6.2)
Newtonsoft.Json (6.0.5)
Respond (1.3.0)
Unquote (2.2.2)
WebGrease (1.6.0)
  Antlr (>= 3.4.1.9004)
  Newtonsoft.Json (>= 5.0.4)
bootstrap (3.2.0)
  jQuery (>= 1.9.0)
jQuery (2.1.1)
xunit (1.9.2)

Should be

bootstrap (3.2.0)
  jQuery (>= 1.9.0)
FsWebAddRegistryEntries (0.1.0.0)
Hyprlinkr (1.1.1)
  Microsoft.AspNet.WebApi.Core (>= 4.0.20710.0)
Microsoft.AspNet.Mvc (5.0.0)
  Microsoft.AspNet.WebPages (>= 3.0.0)
  Microsoft.AspNet.Razor (>= 3.0.0)
Microsoft.AspNet.WebApi (5.2.2)
  Microsoft.AspNet.WebApi.WebHost (>= 5.2.2, <  5.3.0)
Microsoft.AspNet.Web.Optimization (1.1.2)
  Microsoft.Web.Infrastructure (>= 1.0.0)
  WebGrease (>= 1.5.2)
Modernizr (2.6.2)
Respond (1.3.0)
Unquote (2.2.2)
xunit (1.9.2)

jQuery (2.1.1)
Microsoft.AspNet.Razor (3.2.2)
Microsoft.AspNet.WebApi.Client (5.2.2)
  Newtonsoft.Json (>= 6.0.4)
  Newtonsoft.Json (>= 6.0.4)
  Microsoft.Net.Http (>= 2.2.22)
Microsoft.AspNet.WebApi.Core (5.2.2)
  Microsoft.AspNet.WebApi.Client (>= 5.2.2)
Microsoft.AspNet.WebApi.WebHost (5.2.2)
  Microsoft.AspNet.WebApi.Core (>= 5.2.2, <  5.3.0)
Microsoft.AspNet.WebPages (3.2.2)
  Microsoft.Web.Infrastructure (>= 1.0.0.0)
  Microsoft.AspNet.Razor (>= 3.2.2, <  3.3.0)
Microsoft.Web.Infrastructure (1.0.0.0)
WebGrease (1.6.0)
  Antlr (>= 3.4.1.9004)
  Newtonsoft.Json (>= 5.0.4)

Antlr (3.5.0.2)
Microsoft.Net.Http (2.2.28)
  Microsoft.Bcl (>= 1.1.9)
  Microsoft.Bcl.Build (>= 1.0.14)
Newtonsoft.Json (6.0.5)

Microsoft.Bcl (1.1.9)
  Microsoft.Bcl.Build (>= 1.0.14)
Microsoft.Bcl.Build (1.0.21)


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

@bartelink
Copy link
Member Author

I built from source at some point this morning IIRC. No other case-sensitivity issues observed, just sorting in the lock file. Won't get to do proper repro till later but knowing you; things will be long fixed by then!

@bartelink
Copy link
Member Author

Cool, thanks.

So, about the grouping idea... Want to keep this issue closed and the list short or want me to edit primary issue to talk only about that ? // cc @agross

@forki
Copy link
Member

forki commented Sep 19, 2014

TBH didn't understand the grouping

@bartelink
Copy link
Member Author

@forki GTG, will explain later but will try now. Within groups, you sort alpha. Roots are in first group. Direct deps of that group go into group 2. Recurse until all put into groups and save.

@bartelink
Copy link
Member Author

@forki Right, let's try this...

For me, direct references are a lot more interesting than indirect ones.

If I'm using WebApi, and there's a top level package that I add, I don't care if there's a Microsoft.Bcl.Build package most of the time - I don't want to look at it.

If I'm using hyprlinkr and nothing else in the list is referencing it (yet it references Microsoft.AspNet.WebApi.Core), I want to know that.

If WebGrease is using Antlr, I might be interested in that. But not as much as the fact that it was Microsoft.AspNet.Web.Optimization that pulled both of them in.

The grouping above stores has the exact same data as the normal lock file, with an extra blank line between the 3-5 groups. Each indent is the same. Each package has the direct depends in the same format nested underneath. Within each group, the sorting is still case insensitive.

The only difference is that items that are pulled in by others in earlier groups come later.

The stuff at the top is ready to reason about / glance at and/or put at the top of your Paket.dependencies (have to stop uppercasing the P :P). And the stuff at the bottom is stuff like Microsoft.Bcl.Build

Questions? (Will be spiking the algorithm if you're not in a position to to/fro right now)

@bartelink
Copy link
Member Author

Another example:

    DotNetZip (1.9.3)
    FAKE (3.5.1)
    FSharp.Compiler.Service (0.0.59)
    FSharp.Formatting (2.4.24)
      Microsoft.AspNet.Razor (2.0.30506.0)
      RazorEngine (3.3.0)
      FSharp.Compiler.Service (0.0.59)
    Microsoft.AspNet.Razor (2.0.30506.0)
    Microsoft.Bcl (1.1.9)
      Microsoft.Bcl.Build (>= 1.0.14)
    Microsoft.Bcl.Build (1.0.21)
    Microsoft.Net.Http (2.2.28)
      Microsoft.Bcl (>= 1.1.9)
      Microsoft.Bcl.Build (>= 1.0.14)
    Newtonsoft.Json (6.0.5)
    NuGet.CommandLine (2.8.2)
    NUnit (2.6.3)
    NUnit.Runners (2.6.3)
    Octokit (0.4.1)
      Microsoft.Net.Http (>= 0)
    RazorEngine (3.3.0)
      Microsoft.AspNet.Razor (>= 2.0.30506.0)
    SourceLink.Fake (0.3.4)
    UnionArgParser (0.8.0)

Breaks out as:

    DotNetZip (1.9.3)
    FAKE (3.5.1)
    FSharp.Formatting (2.4.24)
      + Microsoft.AspNet.Razor (2.0.30506.0)
      + RazorEngine (3.3.0)
      + FSharp.Compiler.Service (0.0.59)
    Newtonsoft.Json (6.0.5)
    NuGet.CommandLine (2.8.2)
    NUnit (2.6.3)
    NUnit.Runners (2.6.3)
    Octokit (0.4.1)
      + Microsoft.Net.Http (>= 0)
    SourceLink.Fake (0.3.4)
    UnionArgParser (0.8.0)

    FSharp.Compiler.Service (0.0.59)
      -> FSharp.Formatting (0.0.59)
    Microsoft.AspNet.Razor (2.0.30506.0)
      -> FSharp.Formatting (2.0.30506.0)
    Microsoft.Net.Http (2.2.28)
      + Microsoft.Bcl (>= 1.1.9)
      + Microsoft.Bcl.Build (>= 1.0.14)
      -> Octokit (>= 0)
    RazorEngine (3.3.0)
      + Microsoft.AspNet.Razor (>= 2.0.30506.0)
      -> FSharp.Formatting (3.3.0)

    Microsoft.Bcl (1.1.9)
      + Microsoft.Bcl.Build (>= 1.0.14)
      -> Microsoft.Net.Http (>= 1.1.9)
    Microsoft.Bcl.Build (1.0.21)
      -> Microsoft.Bcl (>= 1.0.14)

@forki
Copy link
Member

forki commented Sep 19, 2014

Actually I think this should be solved via #102

@bartelink
Copy link
Member Author

Actually I think this should be solved via #102

Yes, hence "The stuff at the top is ready to reason about / glance at and/or put at the top of your Paket.dependencies " - IOW I agree that the effect of paket simplify is to leave only the top group in the file.

But the paket.lock file is still not necessarily legible, which is the point at hand here.

Also, doing simplifys aggressively all the time can lose important constraints (you might want to pin a speciific json.net and/or consider something that n packages depend on to actually be a primary reference).

@forki
Copy link
Member

forki commented Sep 19, 2014

... googling "legible" .... will be right back ....

@bartelink
Copy link
Member Author

... or do you mean that the work/speccing of the sorting of the lock file should live under that issue? I semi agree but to be honest I'm not interested in complicating that feature unnecessarily - this feature on its own can

  1. give the lockfile a pretty consistent sequence from a point of view of diffs (though on reflection, migth be bad for triggering merge conflicts under heavy change :( )
  2. provide a handy troubleshooting tool
  3. let people gain insight into package relationships.

legible means "can be read" [by humans]

@forki
Copy link
Member

forki commented Sep 19, 2014

Ok let's try to improve the lockfile.

How can we make your idea really obvious? I don't think your proposal is atm.
Nesting might help. Can you come up with different proposals?

@bartelink
Copy link
Member Author

We kinda did this before...

One tension is that trees have redundancy, which doesnt help either the humans or the computer

If it's about emitting a treeset, that's probably best achieved by install -verbose or -describe

Having said that, one key thing is to have the rendering be stable so that diffs over time can be analysed as clearly as alpha sorting can

Let me see if I can do something with nesting all the same though... No - won't work as far too often most stuff at bottom is referenced from very many parents (and the interelationships are not very interesting). Thinking...

Tried inverting the tree, but that doesn't make sense either - each package that depends on a package has a versionspec. So yes, json.net is this version, but there are multiple dependees and we are interested in what they depended on etc. More thinking...

@forki
Copy link
Member

forki commented Sep 19, 2014

Thinking...

That's what I wanted to hear. ;-) I don't think grouping is the way to go.

@bartelink
Copy link
Member Author

It's looking good (though unexpected, and not a tree (which is not surprising as it's all a graph...)). Processing....

@forki Right, ready for review, grouping or not (please re-read from the top - I've edited each sample and added reasoning as to e.g. why a tree won't really make sense). Have left the workings at the top but I think it will be best to remove them and replace with a desc of the algorithm in English once you, @agross, @ilkerde, @theimowski, @isaacabraham and anyone else with an opinion are agreed.

Def interested in getting this assessed and/or refined properly out as I believe this will help a lot to help the product explain itself out in the world without people needing to write (or worse: read :P) docs too much!

Anyone have a paket.lock file they'd like to see re-rendered and/or discuss as an example of how this might be a bad idea?

@bartelink
Copy link
Member Author

@forki Can you review please when you get a chance? I can log a new issue with a fresh summary of the proposal once we've agreed the basics.

@forki
Copy link
Member

forki commented Sep 22, 2014

I do like the idea to make the resolution process visible in the lockfile.

But I don't have time to change the lockfile very soon.

@bartelink
Copy link
Member Author

@forki Totally get that and not pushing for it now. And I'm going to add more to the issues list shortly :(

However, some things I'll be posting will try to use similar patterns, i.e. if I'm proposing a syntax for adding a reference to a package and this shows that as + Package, I want to use the same in the dependencies as this is really a projection from the dependencies graph computation process

My proposal will be retty close #125 and as a result has minor implications (really just making it more consistent) for the lockfile, e.g.:

NUGET
  remote: http://nuget.org/api/v2
  specs:

Would change a bit and the lock and dependencies would share a common style wrt Files and NuGets.

So my question is really - at a high level, is there anything you don't like about the formatting:

  • indenting by 2 and groups (not hierarchy / trees like earlier in this discussion)
  • + for showing child package references
  • -> or some other symbol not used in dependencies to convey inferences the model has made fully respect that this just adds time to the long pole and complexity to the impl at this point.

If you can give that basic reaction, we can let this sit here closed and when it makes sense to revisit the lockfile and/or after it has been visited for a reason we can consider adding this in at that point.

@bartelink
Copy link
Member Author

@forki Should I log a minimal WIP edition of this as an Open issue so others can review/comment? It's kinda in limbo now ?

This was referenced Sep 22, 2014
@bartelink
Copy link
Member Author

Will revise this in light of #154 - will prob do some examples of grouping based on the syntax in it later.

@bartelink
Copy link
Member Author

@forki This one is def superseded by #165 now

If you like (i.e., if you ask or if I don't get an ack at some stage), I can translate the other 2 examples into #165 - I think MVC+WebApi is a pretty good example of how much this can clarify matters but IMO the concept is already plenty clear based on the examples there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants