Sorry, but I'm not even sure I understand what the above means.

While I'm aware that there are people who believe that NuGet isn't a good system, no-one's ever taken the time to clearly explain to me what the problems are (apart from Package Restore, where I'm acutely aware of the problems).

from hyprlinkr.

Paket FizzBin

Commandline tool used to download nugets/files across your entire repo consistently, add them to .vb/.fs/.csprojs. Has restore option so packages dont have to go into source control.

Fast, no mousing/waiting/clicking/progress dialogs, no angle brackets, no gratuitous diffs on updates. It Just Works with/without Xamarin/Visual Studio, Windows/Mono, C#/F#/VB. Updating to latest is up arrow, enter.

You'll especially like it if any of the following is true:

• you use git
• you are in Package Manager Console a lot
• you sometimes feel you're spending too much time/clicks/mouse wheeling/managing merge conflicts on package updates and or scanning for ticks

Dev uses Paket when developing

paket.dependencies: Put paths, package names and version constraints in paket.dependencies file in a dir tree root.

$ paket update: Creates/validates a graph and saves resolved vers to paket.lock.

paket.references: In proj dirs, simple text file lists pakets used in .xxproj files

1. Use NuGet to maintain /packages. paket convert-from-nuget to suck Refs out of packages.config into Deps+Refs files.
2. Edit paket.dependencies or use $ paket add: Add file (\share, Http, GitHub, fssnip) or NuGet specs to deps, Write Lock, Add to Refs for a proj, put ref into a proj
3. $ paket update: Read paket.dependencies, Write Lock, Load Refs, Put <References into csprojs
4. Loop (can go back to -1 if you want - using paket does not preclude use of NuGet)
5. Add paket.dependencies, paket.lock paket.references to source control. Add .nupkg files + DLLs in packages folder to either .gitignore or source control. Commit.

People cloning repo need exact same set of files dev was using but dev didnt commit entire packages folder

1. Fork repo.
2. paket install: read Lock, download .nupkg files iff not there, expand DLLs out of .nupkg zips
3. Load VS.

CI box iff not committing all packages folder

5: <build>.cmd/sh: paket install: Read Lock, download files not in /packages, expand DLLs.

6: Run msbuild/xbuild - no magic scripts slowing anything down

from hyprlinkr.

Contextual answer for why hyprlinkr should use it is:

editing AssemblyInfo.fs files : 029 :: NuGet update busywork/clickery : Paket

i.e. no magical powers you didnt have before, but you'll still wonder where it was all your life.

No mad diffs in updates, quick easy package updates across solutions.

Real no brainer hands down win will be to apply it to AutoFixture but some bugs need to be squashed before I do that.

Sadly no words are any use, you just have to try it really.

Would love feedback on the FizzBin guide in prev comment want to put it failrly prominient on http://fsprojects.github.io/Paket/ soon and want to have something that explains core points and abts back key misconceptions to clued-in people without going all TL;DR.

from hyprlinkr.

Personally, I'm pretty much here:

• you use git Check
• you are in Package Manager Console a lot Check
• you sometimes feel you're spending too much time/clicks/mouse wheeling/managing merge conflicts on package updates and or scanning for ticks not really

Given this, I still don't understand what value Paket provides. Sure, there are a few areas where I think NuGet could be better, but if you abstain from using Package Restore, they are only small things...

You may then tell me that Paket fixes those small things, but when taking on another dependency, there's also a cost associated with that. Is the price worth the benefit? Perhaps, but I don't see it yet.

from hyprlinkr.

Based on the above I think your stance is perfectly valid.

Especially for libs like hyprlinkr and AutoFixture where you're being extremely deliberate about all what minimum bars you set (e.g. being conservative re Moq ver etc.).

I think on the AutoFixture suite, being able to create sets of dependencies to apply as a "profile" might make sense.

Or if you have a suite of independent services whose dependencies break down into sets may provide a useful abstraction, see fsprojects/Paket#154 (examples in fsprojects/Paket#165 and fsprojects/Paket#123)

In all cases, as you're pretty much saying, the abstraction better be earning its keep vs the conceptual cost. And it should be introduced for a reason better than it being cool. I guess one could say it's a bit like "listen to your testsdependencies" and the good effects of Pure DIexplicit NuGet project level references being a good exercise. Maybe Paket equates to Resharper to complete the set of allusions to the sets of your concepts that are firing in my head :)

Thanks for the time - this has definitely helped out my thought process though, fsprojects/Paket#176 is a direct result.

I'm also hoping that as a side effect of fsprojects/Paket#166 NuGet itself will gain a mode where you can just commit nupkgs without all the lib dirs expanded out and a NuGet restore as step 1 of a build will (without having a network dep) expand the DLLs and save a lot of repo bloat (and hopefully build time).

I'm stil also going to try it on AutoFixture too though nonetheless.

from hyprlinkr.

Well, if the light bulb eventually lights up for me, I certainly wouldn't mind; I reserve the right to revise my position when I've become less ignorant :)

from hyprlinkr.