Yes, sadly, we are severely constrained by being one of the several OSS projects in the .NET ecosystem with what I would have to term "packaging needs that do not appear to have been part of the design considerations of NuGet when it was conceived". NuGet presently addresses only the most basic (and completely STATIC) of package dependency relationships. At least at this time, the capabilities of more mature package managers in other ecosystems remain disappointingly out of reach for NuGet.
One can hope that as NuGet achieves broader adoption and the ubiquity of such needs becomes more acute that NuGet will mature enough to permit us to design packages that match how we'd prefer to assemble things rather than having to operate within the existing constraints. In the mean time, of course, we have to find a way via workarounds, hacks, and other unpleasant 'tricks' to provide 'hints' to the user re: how to use NuGet to consume non-trivial package dependencies. "You must live in the world you have, but at the same time try to make the world you want." :) Steve Bohlen [email protected] http://blog.unhandled-exceptions.com http://twitter.com/sbohlen On Mon, Mar 14, 2011 at 4:59 AM, Oskar Berggren <[email protected]>wrote: > I know absolutely nothing about Nuget, but in a wider context this > scenario is a solved problem: Consider Debian and Ubuntu packages. If > nuget had those capabilities, there would be an NHibernate package > with all the usual content. This package would DEPEND on a virtual > package NHibernate.ProxyFactory. This package would not actually exist > as a directly installable entity, but would be PROVIDED by the > concrete packages NHibernate.Castle, NHibernate.LinFu, etc. > > So the dependency engine would be happy if any of those proxy factory > packages were installed, and there is enough information there to > display a "choose package" gui to the user, when NHibernate has been > selected. > > Debian also has a RECOMMENDS capability, for soft "dependencies", i.e. > NHibernate could RECOMMEND ConfOrm, FluentNHibernate, etc. as a hint > to the user. > > Now if only Nuget would get fixed.... :) > > /Oskar > > > 2011/3/14 Richard Brown (gmail) <[email protected]>: > > On question 1: Castle seems like the sensible option to me. In addition > to > > (currently) providing the most functionality I’m guessing it has the > widest > > current adoption (since many projects will have used NHibernate before > the > > implementation of ProxyFactoryFactory); > > > > On question 2: I’m happy with the naming convention. > > > > > > Will there be any issues with changing the default package to point to a > > different proxy implementation if (say) LinFu becomes the preferred > default > > option at a future date? That is, can we reasonably expect everyone’s > > projects to happily accept a silent update to which proxy they are using > ... > > especially when they still have to explicitly configure the proxy (either > > programmatically or in .config files)? > > > > > > From: Stephen Bohlen > > Sent: Sunday, March 13, 2011 11:22 PM > > To: [email protected] > > Subject: Re: [nhibernate-development] Re: NHibernate 3.x NuGet packaging > > (re)design > > > > There is no actual 'first-class' aliasing facility in NuGet (sadly), but > > your suggestion *is* implementable, if 'indirectly'. By defining > > 'Nhibernate' as only an 'empty' package with nothing but a dependency on > > Nhibernate.Castle, in effect it would have 'alias' support AFAIK. This > > would have the benefit of a) avoiding an additional 'actual' package > (with > > content) that we'd have to maintain and b) provide a simple mechanism to > > switch the default if we wanted to do so at some future point (for any > > reason). Effectively we would then need to just re-state the > > dependency(ies) for the 'Nhibernate' package as being (example) > > "Nhibernate.LinFu" instead of "Nhibernate.Castle" as would be the initial > > case as of now. > > > > I like the idea (less to maintain/keep in sync). > > > > Steve Bohlen > > [email protected] > > http://blog.unhandled-exceptions.com > > http://twitter.com/sbohlen > > > > > > On Sun, Mar 13, 2011 at 7:16 PM, Richard Birkby <[email protected]> > wrote: > >> > >> Would it be possible for NHibernate to depend only on NHibernate.Castle, > >> thus becoming essentially an alias. In fact, does Nuget support a 1st > class > >> alias facility? > >> > >> I like calling it Core. It's exactly what I had in mind before I read > your > >> proposal. > >> > >> Richard > >> On 13 Mar 2011, at 21:37, Stephen Bohlen <[email protected]> wrote: > >> > >> Sorry, since I copied and pasted the list of packages, I failed to > >> (completely) edit the second of the two list of packages (showing those > >> proposed). > >> > >> Here's the list of proposed package structure as I *meant* to provide > it: > >> > >> ******** > >> Package: "NHibernate.Core" > >> Semantic Contents: the nhibernate.dll assembly > >> Dependencies: none > >> ******** > >> Package: NHibernate > >> Semantic Contents: the ProxyFactoryFactory for Castle > >> Dependencies: "NHibernate.Core", <the Castle dynamic proxy > assembly(ies)> > >> ******** > >> Package: NHibernate.Castle > >> Semantic Contents: the ProxyFactoryFactory for Castle > >> Dependencies: "NHibernate.Core", <the Castle dynamic proxy > assembly(ies)> > >> ******** > >> Package: NHibernate.LinFu > >> Semantic Contents: the ProxyFactoryFactory for LinFu > >> Dependencies: "NHibernate.Core", <the LinFu dynamic proxy assembly(ies)> > >> ******** > >> Package: NHibernate.Spring > >> Semantic Contents: the ProxyFactoryFactory for Spring.NET > >> Dependencies: "NHibernate.Core", <the Spring.NET dynamic proxy > >> assembly(ies)> > >> ******** > >> > >> That's what I get for typing too fast... :) > >> > >> Steve Bohlen > >> [email protected] > >> http://blog.unhandled-exceptions.com > >> http://twitter.com/sbohlen > >> > >> > >> On Sun, Mar 13, 2011 at 5:31 PM, Stephen Bohlen <[email protected]> > wrote: > >>> > >>> As discussed elsewhere, Fabio (with some periodic input from myself) > has > >>> been working to define NuGet packaging structures for NH3.x. > >>> > >>> As presently designed, the packaging structure for NH3.x looks like > this > >>> (*generalized* so you get the idea; this is NOT exactly their full > contents, > >>> but an abstract of how they are structured): > >>> > >>> ******** > >>> Package: NHibernate > >>> Semantic Contents: the nhibernate.dll assembly > >>> Dependencies: none > >>> ******** > >>> Package: NHibernate.Castle > >>> Semantic Contents: the ProxyFactoryFactory for Castle > >>> Dependencies: "NHibernate", <the Castle dynamic proxy assembly(ies)> > >>> ******** > >>> Package: NHibernate.LinFu > >>> Semantic Contents: the ProxyFactoryFactory for LinFu > >>> Dependencies: "NHibernate", <the LinFu dynamic proxy assembly(ies)> > >>> ******** > >>> Package: NHibernate.Spring > >>> Semantic Contents: the ProxyFactoryFactory for Spring.NET > >>> Dependencies: "NHibernate", <the Spring.NET dynamic proxy > assembly(ies)> > >>> ******** > >>> > >>> Essentially, the "Nhibernate" package is 'bare' NH3.x with no > >>> ProxyFactoryFactory included and is intended only to be used as a > 'reference > >>> package' for other packages (either created by NH team or otherwise) > that > >>> for any particular reason do not want/need any of the specific > >>> ProxyFactoryFactory packages. > >>> > >>> The design intent here was that the 'typical' NH adopter would select > one > >>> of the "Nhibernate.<proxyfactory>" packages that was to their liking. > >>> > >>> While this approach would seem to achieve this goal, its not without > its > >>> limitations, as many have pointed out in various venues: > >>> > >>> naming the 'bare' (proxy-less) package simply "NHibernate" is > potentially > >>> confusing as its 'generic' name increases the likelihood that it will > be > >>> selected by a high percentage of adopters unaware of the nuances of > needing > >>> to select one of the higher-level (ProxyFactoryFactory) packages; this > is > >>> likely to result in people adding this package in error and not ending > up > >>> with a complete, fully-functional NH-based solution (and no clear > indication > >>> to them as to why this is the case) > >>> this approach requires the NH adopter to make a conscious decision when > >>> adding their desired package re: which ProxyFactoryFactory > infrastructure > >>> they want to use; it has been suggested elsewhere that this represents > an > >>> "implementation detail" within NH that the vast majority of NH adopters > >>> should not want/need to concern themselves with > >>> > >>> From the beginning of the introduction of the ProxyFactoryFactory, NH > has > >>> refrained from making any one of the ProxyFactoryFactory > implementations > >>> 'the default' and has treated all proxy engines equally. If we choose > to > >>> shield the user from this implementation detail in our packaging by > >>> providing a 'default' for the 'standard' NH package, then we need to > decide > >>> which ProxyFactoryFactory implementation will be that default. > >>> > >>> At first glance, the logical choice seems to be the LinFu proxy engine > >>> since its the the lightest-weight of those available (because its > >>> narrowly-focused on being 'only' a dynamic proxy engine and is not also > >>> trying to be an IoC container at the same time). Because of its more > narrow > >>> scope/feature set, its also probably the least-likely to > version-collide > >>> with other assemblies in users' projects. > >>> > >>> However, since the Castle dynamic proxy engine is presently the only > one > >>> of the several to support the 'full' set of NH features (e.g., lazy > >>> properties), this probably makes it the best choice as the 'default' > >>> ProxyFactoryFactory (at least until features like lazy-properties can > be > >>> supported by the LinFu dynamic proxy). > >>> > >>> So I am proposing the following revision to the present packaging > >>> approach and asking for comment/feedback on this re-design: > >>> > >>> ******** > >>> Package: "NHibernate.Core" > >>> Semantic Contents: the nhibernate.dll assembly > >>> Dependencies: none > >>> ******** > >>> Package: NHibernate > >>> Semantic Contents: the ProxyFactoryFactory for Castle > >>> Dependencies: "NHibernate.Core", <the Castle dynamic proxy > assembly(ies)> > >>> ******** > >>> Package: NHibernate.Castle > >>> Semantic Contents: the ProxyFactoryFactory for Castle > >>> Dependencies: "NHibernate", <the Castle dynamic proxy assembly(ies)> > >>> ******** > >>> Package: NHibernate.LinFu > >>> Semantic Contents: the ProxyFactoryFactory for LinFu > >>> Dependencies: "NHibernate", <the LinFu dynamic proxy assembly(ies)> > >>> ******** > >>> Package: NHibernate.Spring > >>> Semantic Contents: the ProxyFactoryFactory for Spring.NET > >>> Dependencies: "NHibernate", <the Spring.NET dynamic proxy > assembly(ies)> > >>> ******** > >>> > >>> This revised approach is intended to ameliorate most of the perceived > >>> shortcoming of the existing packaging design by: > >>> > >>> using "NHibernate.Core" as the name of the 'bare' nh package; this > (when > >>> present in the NuGet list alongside the new plain 'Nhibernate' package) > >>> should help to discourage users from inappropriately referencing it > directly > >>> (fingers crossed here!) > >>> making the 'plain' "NHibernate" package a fully-functional distribution > >>> that will "just work" for adopters (provided, of course, that they > properly > >>> configure NH once adding the package <g>); its *hoped* that naming it > just > >>> plain "NHibernate" will increase the chances that adopters will select > it as > >>> the package to add (e.g., its name matches "what they were looking > for") > >>> still offering the original ProxyFactoryFactory-specific packages for > >>> those adopters 'more aware' of the pros and cons of their making a > specific > >>> choice > >>> > >>> Before we proceed to make any of these modifications, we would like > some > >>> feedback re: this planned approach in the following areas: > >>> > >>> please comment on the proposed choice of Castle as the dynamic proxy > >>> engine for the 'default' NH package > >>> please comment on the proposed new structure of package dependencies > >>> > >>> Thanks in advance, > >>> > >>> Steve Bohlen > >>> [email protected] > >>> http://blog.unhandled-exceptions.com > >>> http://twitter.com/sbohlen > >> > >> > > > > >
