I might be able to use the vanilla PackageBuilder, but I'm not sure. I still feel like the refactorings I made to the core are valid. All I really did was call out the difference between Metadata, Package Files, and Writing a package.
The ability to compose together Metadata, i.e. information from using Mono.Cecil against an assembly, metadata from a nuspec file, and then use just the assembly as the Package File has been very useful.
So the context was to open up the core a little bit more to make usage of the API a bit more extensible.
My reasoning is that if people are happy with the refactorings in the core, and the changes to support "plugins" then we can have discussion about particular usages of those changes.
For instance my 'packsolution' command might not be whatever one needs, but it's working well for me and has some of those original features we discussed. When it builds a package for a project it looks at packages.config and Project References to
build the set of dependencies for the package, uses Mono.Cecil (implemented behind IPackageMetadataProvider) to scrape Id, Authors, Owners, etc from the Projects assembly, and finally outputs a package with just that project assembly.
Now that could, and might even need to change in behavior, depending on what I encounter as I use it more. But the changes in vanilla NuGet to support that command seem minimal to me, considering what we're enabling.
Was there something particular about my changes that seems troublesome? The original review cycle we did about a month ago now seemed more concerned with code idioms and formatting. Since then I've removed the commands I added, but left the core
changes, and enabled plugins which is pretty straightforward with MEF.