search

ploeh / Hyprlinkr

A URI building helper library for ASP.NET Web API
MIT License
198 stars 34 forks source link

Use Paket #33

Closed bartelink closed 9 years ago

bartelink commented 9 years ago

I've been trialling porting Hyprlinkr to use Paket.

At present, there are 2 open issues that have material effect fsprojects/Paket#163 and fsprojects/Paket#161

(Side note: #164 should be fixed v soon and could waste time...)

However, even at this point, aside from the workarounds which should not be necessary for long, switching just involves the removal of explicit build versions from 2 lines in build.config and addition of an explicti ref to NuGet.CommandLine in the sln-level packages.config.

I'd be happy to do a PR if you want but I assume given how doing a paket convert-from-nuget a good intro to Paket and that the best time to do this kind of mucking about is when someone is adding something concrete to act as a ship vehicle I'm happy for this issue to be read, acked and closed.

ploeh commented 9 years ago

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).

bartelink commented 9 years ago

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:

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

bartelink commented 9 years ago

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.

ploeh commented 9 years ago

Personally, I'm pretty much here:

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.

bartelink commented 9 years ago

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.

ploeh commented 9 years ago

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 :)