NuGet package 616 - dependencies and references

[Damian Hickey]

Hello all,

I've a few comments regarding the experience of adding a RavenDB nuget package to a project. Currently, the following dependencies are added to a standard class library project:

1. AsyncCtpLibrary
2. Newtonsoft.Json
3. NLog
4. Raven.Abstractions
5. Raven.Client.Debug
6. Raven.Client.Lightweight
7. Raven.Client.MvcIntegration
8. System.ComponentModel.Composition

My initial impression is the this is a bit heavy especially if one just wants to use IDocumentStore in a few projects in a solution. I consider the RavenDB package to a 'low' level type of library, sort of similar to System.Data(.SqlClient), in that I'd expect and be as self contained as possible.

1) AsyncCtpLibrary could potentially be ilmerged and internalized into Raven.Client.Lightweight (as a post build step / psake build task). Or can use nuspec <files> to exclude it from referenced?

2) Newtonsoft.Json has types exposed on public api such as JsonContractResolver property on DocumentConvention so not much we can do here. Would prefer my project not to see it to be honest.

3) NLog is what I would consider to be a application level dependency i.e. referenced at the composite root. I'd prefer my projects not reference it directly. Also perhaps may cause problems with different versions or a dev wants to use a different logger. I suggest an ILog interface in Raven.Abstractions and a static LogProvider instead of referencing Nog.LogManager directly in code. Can provide an NLog \ Log4Net adapter seperated or just as documentation for other users to plug in.

5) Debugger visualizer is useful, but would consider putting this in a seperate nuget package for reference by test projects, if so desired.

6) This is dependent on System.Transactions which is not declared in the package's <frameworkAssemblies>. (Will there be a Raven.Client.Heavyweight?)

7) Raven.Client.MvcIntegration - that is only of interest to Mvc projects? Seperate NuGet package perhaps? It is dependent on System.Web and System.Web.MVC which are not declared in the NuGet package <frameworkAssemblies>. Not saying they should be, just saying because...

8) Exposed by attribute on AbstractIndexCreationTask and *is* declared via <frameworkAssemblies>. So, some inconsitencies between 6 / 7 & 8.

In short what I'd like to see, or as close as possible, is just these references added:

1. Raven.Abstractions
2. Raven.Client.Lightweight

You thoughts please?

Btw, I reserve the right to be wrong and of course willing to do any work as a result of this discussion :)

Cheers,

- Damian

[Oren Eini (Ayende Rahien)]

1) We can avoid referencing the AsyncCtpLibrary, I guess.

2) Exposing json.net gives you a lot of power, actually.

3) We can avoid referencing NLog, but I am not going to introducing an abstraction for that. 

5) We can do that, yes.

6) We don't need to do that, if you want to use TransactionScope, you'll do that, and we will integrate with that.

7) There isn't a way to add something just to MVC projects, and I want to avoid having bazziliion nuget packages.

8) Yes, that is because this can cause compilation issues, the others do not.

Damian,

I will be honest and say that I actually pay very little attention to the way nuget works.

Would you be able to send a pull request for those changes? Specifically, 1,5,7 would be great.

[Damian Hickey]

Sure, should get some cycles to spend on it this week.

[Oren Eini (Ayende Rahien)]

Thanks

[Itamar Syn-Hershko]

Damian, a short note (and sorry about the lagged response):

5. Debugger visualizer - let's not create yet another nuget package for it, instead just have it excluded from references and anyone who wants that can reference it later on.

7. Ditto

[Damian Hickey]

No problem Itamar, only getting around to it now.

I'm in two minds whether additional packages are worth it or not. The only thing is that if a reference is manually added and the developer updates the package through nuget, those references will have to be re-added manually. You ok with that?

To specify explicit assembly references I have to use nuspec's <reference> element. I can codify this in the build script (default.ps1) or create a separate nuspec for the client. What is the team's preference? Personally, I'm a nuspec-file-per-package kinda person, so I'm wondering if there was a concious decision to do it all in the build script?

I'll do the AsyncCtpLibrary dependency removal on the client in a separate pull request. Heard from a colleague that it was causing a conflict in VS11/.net4.5 too.

On Wednesday, 7 March 2012 22:34:37 UTC, Itamar Syn-Hershko wrote:

Damian, a short note (and sorry about the lagged response):

5. Debugger visualizer - let's not create yet another nuget package for it, instead just have it excluded from references and anyone who wants that can reference it later on.

7. Ditto

[Fitzchak Yitzchaki]

inline

On Sun, Mar 11, 2012 at 10:21 PM, Damian Hickey <dhi...@gmail.com> wrote:

No problem Itamar, only getting around to it now.

I'm in two minds whether additional packages are worth it or not. The only thing is that if a reference is manually added and the developer updates the package through nuget, those references will have to be re-added manually. You ok with that?

To specify explicit assembly references I have to use nuspec's <reference> element. I can codify this in the build script (default.ps1) or create a separate nuspec for the client. What is the team's preference? Personally, I'm a nuspec-file-per-package kinda person, so I'm wondering if there was a concious decision to do it all in the build script?

Yes, we prefer the have one nuspec file and the build script to do modifications to it.

I'll do the AsyncCtpLibrary dependency removal on the client in a separate pull request. Heard from a colleague that it was causing a conflict in VS11/.net4.5 too.

We are going to support both SL4 and SL5 so it should be removed just for SL5 project.

Look on this related issue: http://issues.hibernatingrhinos.com/issue/RavenDB-86 

[Itamar Syn-Hershko]

On Sun, Mar 11, 2012 at 10:21 PM, Damian Hickey <dhi...@gmail.com> wrote:

No problem Itamar, only getting around to it now.

I'm in two minds whether additional packages are worth it or not. The only thing is that if a reference is manually added and the developer updates the package through nuget, those references will have to be re-added manually. You ok with that?

Yes

 

To specify explicit assembly references I have to use nuspec's <reference> element. I can codify this in the build script (default.ps1) or create a separate nuspec for the client. What is the team's preference? Personally, I'm a nuspec-file-per-package kinda person, so I'm wondering if there was a concious decision to do it all in the build script?

The build script is creating the folder structure to pack into nupkg and then it can have list of DLLs we want to explicitly de-reference

[Damian Hickey]

Gent's,

as a result of Ayende's blog post on NuGet, another thread regarding an FSharp dependency, and a brief email from Ayende (I did a 'reply to author' instead of to the group, my bad), I am going to make an attempt at doing fine-grained packages.

Let me spend some cycles on it and see if I arrive at something that is maintainable and satisfactory. It may be week or so...

Cheers

Damian

On Monday, 12 March 2012 21:02:11 UTC, Itamar Syn-Hershko wrote:

[Fitzchak Yitzchaki]

Great! looking forward to see what you've got...

[Damian Hickey]

I do think it will add _some_ maintenance cost, but I believe the end-user experience will be worth it, I hope ;)