I'm for convert-from-nuget command.

I'm not sure. (Sorry to be awkward). Part of the point of paket is to separate direct from indirect dependencies - but it won't have enough information to do that from the nuget files (that's kind of why we need paket in the first place!). So I think we can auto-create paket.reference files, but I can't see anyway we can create sensible packet.dependencies without importing all of the wrong assumptions nuget has already made.

It's important to learn about your project's dependencies so the manual transition is valuable.

that's what I meant. But the convert command and the especially the generated lock file will give you a much better starting point.

How if paket usurp walks the package.configs and generates deps and refs with a minimal set of deps, i.e. only the roots

I think another useful thing to hook into such a command is tpo have it report use pof .ps1 files and other such constructs in child packages

(And short term known issues such as not supporting .props and/or .targets)

@bartelink if we're going to have an automated command, that's what it should do. Which I suspect will surprise some people with how short the dep file actually is!

should paket usurp above be called paket simplify or paket decomplect instead :P ?

I'm leaning towards simplify as I had to look up the other word's definitions :)

@mavnn Actually you're extremely right - it came as a a surprise to me that the 8ish packages the F# MVC 5 template adds boils down to Microsoft.AspNet.WebApi and bootstrap (I had to walk the WebApi package hierarchy to suss it out).

One potential thing to consider is if someone e.g. is referencing bootstrap 3.0.2, then there's a stub Twitter.bootstrap 302 returning a 200 redirect message. And whether the genned file should have = 3.0.2 or something else (and maybe a comment giving alternatives?).

decomplect is very clojurish. nice one ;-)

@agross You will LOVE http://www.infoq.com/presentations/Simple-Made-Easy and his related talks; they are absolutely key talks about programming and compexity. Ditto Hamock driven Development and the datomic / event sourcing talks re Place Oriented Programming.

He spends a long time explaing the problems of complecting things.. Complect is to a large degree an archaic word but is a critical concept in understanding our craft. The specific point in this context being that package.config combines too many things.

decomplect is definitely not a commonly used term and hence toungue in cheek and inappropriate here.

usurp is similarly tongue in cheek (I would vote against it whereas I wouldnt vote against decomplect as ultimately one is talking about an opinionated evolving process that one does not want people assuming anything about and not understanding the limitations/constraints of the process)

So do we have any volunteers?

I think the simplification should be a second command since it would also make sense in other settings.#102

I can give it a try

What should we write to paket.dependencies if there are different versions of the same package in separate package.configs?
Should we remove packages directory afterwards?

@theimowski Take the highest version and warn about the version mismatch?

@theimowski I'm with @agross . Only other addition is that it should error out (hopefully without writing changes!) if there is no version of a dependency that can be used across all projects.

This is possible when using version ranges rather than just "this version or above"

@agross Sorry for being paranoid again. In large enterprise repos (~500 projects and larger) this scenario is likely to happen.

Automatically resolving to highest is sort of the credo of Paket (since we already embrace SemVer to follow deps).

However, I'm not sure if this is too much "automagic" fixing. Me prefers explicit choice of user. This is transparent behavior giving user a balanced notion of responsibility. Ntl, I'm ok with the auto-resolve if you are very keen about it.

@mavnn How does one determine if a specific version of NuGet package can be used in a project?

@theimowski having thought about this a bit further, this probably isn't the right place to do the analysis; thinking about it, it's the generation of the lockfile that should deal with these kinds of issues. So I think the logic for generating the dependencies file would become:

1. Detect packages which are dependencies of other packages. Ignore them. I suspect this requires loading all of the dependencies of all of the packages, and then doing a set operation of (all package name - all dependency names)
2. With the packages that are left, set the required version to the highest version in any of the packages.config files
3. Convert package.config files to paket.reference by removing formatting/version numbers as required

From that point on let paket generate lock files as normal.

We need a warning somewhere to let people know that there is no guarantee that the resulting paket configuration will be valid (it might be impossible to create a lock file that matches all of the constraints, for example)

Detect packages which are dependencies of other packages

I think @forki would like this to be a separate "simplify" command as stated in #102,
so that after converting from nuget, paket.dependencies would have all the dependencies listed in package.config files. Is that right?

@theimowski That's how I'd read it (and the same would apply to [*.]paket.references files too)

Closed with #105 - please reopen for bugs.

@bartelink Thanks for the video recommendation. Excellent presentation, lots of food for thought!

@agross Glad you liked. I'm currently hiding from the guilt of not having started on https://github.com/JanVanRyswyck/awesome-talks and instead listening to far inferior stuff. If there was a Rich Hickey talk you enjoyed that wasnt on that list it might be good to put it there. And if bored after that, http://functionaltalks.org/ is also on my list!