Repository navigation
Make transition from NuGet even easier #99
Description
It's important to learn about your project's dependencies so the manual transition is valuable.
That said: getting users to switch to Paket could be much easier. We already implemented --hard (see http://fsprojects.github.io/Paket/convert_from_nuget.html), but I'm dreaming of the following:
- we read every packages.config file and extract the referenced NuGet packages and put them into a new paket.dependencies file
- we convert every packages.config file into a paket.references file and rename it
- we run paket install --hard
we could do this as a new command "paket convert-from-nuget".
Activity
vasily-kirichenko commentedon Sep 15, 2014
I'm for
convert-from-nugetcommand.mavnn commentedon Sep 15, 2014
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.
forki commentedon Sep 15, 2014
that's what I meant. But the convert command and the especially the generated lock file will give you a much better starting point.
bartelink commentedon Sep 15, 2014
How if
paket usurpwalks thepackage.configs and generatesdepsandrefswith a minimal set of deps, i.e. only the rootsI think another useful thing to hook into such a command is tpo have it report use pof
.ps1files and other such constructs in child packages(And short term known issues such as not supporting
.propsand/or.targets)mavnn commentedon Sep 15, 2014
@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!
bartelink commentedon Sep 15, 2014
should
paket usurpabove be calledpaket simplifyorpaket decomplectinstead :P ?agross commentedon Sep 15, 2014
I'm leaning towards
simplifyas I had to look up the other word's definitions :)bartelink commentedon Sep 15, 2014
@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.WebApiandbootstrap(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 stubTwitter.bootstrap302 returning a 200 redirect message. And whether the genned file should have= 3.0.2or something else (and maybe a comment giving alternatives?).forki commentedon Sep 15, 2014
decomplectis very clojurish. nice one ;-)bartelink commentedon Sep 15, 2014
@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
complectingthings.. 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 thatpackage.configcombines too many things.decomplectis definitely not a commonly used term and hence toungue in cheek and inappropriate here.usurpis similarly tongue in cheek (I would vote against it whereas I wouldnt vote againstdecomplectas 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)forki commentedon Sep 15, 2014
So do we have any volunteers?
forki commentedon Sep 15, 2014
I think the simplification should be a second command since it would also make sense in other settings.#102
theimowski commentedon Sep 15, 2014
I can give it a try
theimowski commentedon Sep 15, 2014
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?
agross commentedon Sep 15, 2014
@theimowski Take the highest version and warn about the version mismatch?
mavnn commentedon Sep 15, 2014
@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"
ilkerde commentedon Sep 15, 2014
@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.
theimowski commentedon Sep 15, 2014
@mavnn How does one determine if a specific version of NuGet package can be used in a project?
mavnn commentedon Sep 15, 2014
@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:
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)
theimowski commentedon Sep 15, 2014
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?
bartelink commentedon Sep 15, 2014
@theimowski That's how I'd read it (and the same would apply to
[*.]paket.referencesfiles too)forki commentedon Sep 16, 2014
Closed with #105 - please reopen for bugs.
agross commentedon Sep 17, 2014
@bartelink Thanks for the video recommendation. Excellent presentation, lots of food for thought!
bartelink commentedon Sep 17, 2014
@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!
Merge pull request #99 from forki/Github