RFC: Naming Conventions

Editor
Nov 3, 2010 at 10:25 PM

As things get big, I’m noting naming stuff looking sloppy. DavidEbbo has talked about this a number of times. Here’s a rollup and expansion proposal, with examples. Note that these examples don’t necessarily exist as packages yet.

RFC using Ninject as an example:

Package Naming Conventions RFC

Ninject

The actual Ninject Library. Suitable for ANY project type. The core lib.

Ninject.MVC3

A package that depends on Ninject but includes MVC3 specific helpers and/or wireup.

Ninject.Silverlight, Ninject.IIS, etc.

See above, the idea being [*.WinForms, *.WebForms, *.WinPhone7, *.W?F, etc]

Ninject.Source

The source.

Ninject.Examples

You get the idea.

We miss any?

Thoughts? If there is a simple convention we can agree on, it can be promoted to Docs.

--

Scott Hanselman - Principal “Community Architect” - Microsoft Web Platform

Blog and Podcast: http://hanselman.com – Twitter: @shanselman

Nov 3, 2010 at 10:29 PM
Ninject.Contrib for things that don't fit clearly in the others?

/kzu

--
Daniel Cazzulino | Developer Lead | MS MVP | Clarius Consulting | +1 425.329.3471


On Wed, Nov 3, 2010 at 18:26, shanselman <notifications@codeplex.com> wrote:

From: shanselman

As things get big, I’m noting naming stuff looking sloppy. DavidEbbo has talked about this a number of times. Here’s a rollup and expansion proposal, with examples. Note that these examples don’t necessarily exist as packages yet.

RFC using Ninject as an example:

Package Naming Conventions RFC

Ninject

The actual Ninject Library. Suitable for ANY project type. The core lib.

Ninject.MVC3

A package that depends on Ninject but includes MVC3 specific helpers and/or wireup.

Ninject.Silverlight, Ninject.IIS, etc.

See above, the idea being [*.WinForms, *.WebForms, *.WinPhone7, *.W?F, etc]

Ninject.Source

The source.

Ninject.Examples

You get the idea.

We miss any?

Thoughts? If there is a simple convention we can agree on, it can be promoted to Docs.

--

Scott Hanselman - Principal “Community Architect” - Microsoft Web Platform

Blog and Podcast: http://hanselman.com – Twitter: @shanselman

Read the full discussion online.

To add a post to this discussion, reply to this email (nuget@discussions.codeplex.com)

To start a new discussion for this project, email nuget@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Editor
Nov 3, 2010 at 10:33 PM

Sure.

Also, what about this controversial idea?

Guy is in a console app, and types

install-package ELMAH

And has a bad experience.

I propose that at a minimum, only projects whose core works anywhere would have a simple name like ELMAH. In this example, we’d name it ELMAH.Web. There would be no “just ELMAH.”

Thoughts? This thinking make sense?

Nov 3, 2010 at 10:46 PM
we're going down the road VS extensibility has already gone.

in the end, you should say which project types (GUIDs :( ) your library works with. that's the only reliable way to identify what you're doing in VS.

/kzu

--
Daniel Cazzulino | Developer Lead | MS MVP | Clarius Consulting | +1 425.329.3471


On Wed, Nov 3, 2010 at 18:34, shanselman <notifications@codeplex.com> wrote:

From: shanselman

Sure.

Also, what about this controversial idea?

Guy is in a console app, and types

install-package ELMAH

And has a bad experience.

I propose that at a minimum, only projects whose core works anywhere would have a simple name like ELMAH. In this example, we’d name it ELMAH.Web. There would be no “just ELMAH.”

Thoughts? This thinking make sense?

Read the full discussion online.

To add a post to this discussion, reply to this email (nuget@discussions.codeplex.com)

To start a new discussion for this project, email nuget@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Coordinator
Nov 3, 2010 at 10:49 PM

Sure. I think we need to be careful about how far we take this convention, but I think it can be useful as a quick means of determining whether a package is right for you. I wonder if Ninject should be Ninject.Core instead?

Also, would Ninject.Mvc mean it works for all MVC versions? Or would he need a Ninject.Mvc1 and Ninject.Mvc2 package? Some of these issues may get resolved as we start improving our support for framework targeting, in which case we’d hopefully only need one package for MVC “Ninject.Mvc”.

Nov 3, 2010 at 10:54 PM
I would not go so far as to say. the core package can be applied to any class library. I would rather have a validate.ps1 I could write that would validate the pre-req. for my package. For example MvcContrib is the name of a package. Using your proposed convention I would need to name it. MvcContrib.MVC ? is that too verbose? I would rather apply some powershell that prevents this package from being applied to say. a console app instead of making the name longer. The brand of the project is MvcContrib so the core should match that name.
Editor
Nov 3, 2010 at 10:58 PM
You had me until you said “GUIDs.”
Nov 3, 2010 at 10:59 PM
or some sort of extensible pre-conditions specified declaratively that nuget could add over time, such as :

<Requires>
<AssemblyReference>System.Web</AssemblyReference>
<ProjectType>GUID</>
<IIS>

or whatever ;)

much better than writing powershell ;)

it may even be an extension to the dependency that exists today, taking it beyond nuget dependencies ("external dependencies"?)

/kzu

--
Daniel Cazzulino | Developer Lead | MS MVP | Clarius Consulting | +1 425.329.3471


On Wed, Nov 3, 2010 at 18:55, erichexter <notifications@codeplex.com> wrote:

From: erichexter

I would not go so far as to say. the core package can be applied to any class library. I would rather have a validate.ps1 I could write that would validate the pre-req. for my package. For example MvcContrib is the name of a package. Using your proposed convention I would need to name it. MvcContrib.MVC ? is that too verbose? I would rather apply some powershell that prevents this package from being applied to say. a console app instead of making the name longer. The brand of the project is MvcContrib so the core should match that name.

Read the full discussion online.

To add a post to this discussion, reply to this email (nuget@discussions.codeplex.com)

To start a new discussion for this project, email nuget@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Nov 3, 2010 at 11:00 PM
yup, VS should be called the GUIDE

haha

/kzu

--
Daniel Cazzulino | Developer Lead | MS MVP | Clarius Consulting | +1 425.329.3471


On Wed, Nov 3, 2010 at 18:58, shanselman <notifications@codeplex.com> wrote:

From: shanselman

You had me until you said “GUIDs.”

Read the full discussion online.

To add a post to this discussion, reply to this email (nuget@discussions.codeplex.com)

To start a new discussion for this project, email nuget@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Coordinator
Nov 3, 2010 at 11:02 PM

Well we can only protect people so much. We should look at how reasonable and likely these scenarios are. Why is the person installing ELMAH in the first place? How did they find out about the package that led them to believe it would work in the console? Are people installing random packages into their projects all the time? Or do we think they probably will do at least some rudimentary research first?

I do think in the cases where you have multiple packages each targeting a different scenario (Ninject, Ninject.MVC, Ninject.Silverlight) it makes a lot of sense because when you search for Ninject, you’ll see these other options and potentially find one that’s a better fit for you. But in the case where there’s only one package and it only targets one scenario, I don’t think it’s as big a deal. If there’s only ELMAH, then the naming convention isn’t as big a deal for targetting.

My $0.02 J

Editor
Nov 3, 2010 at 11:05 PM

I’m imagining a world where I’m looking at list-package returning 10,000 records. I’d like to list-package *.Web and have it just work.

Nov 3, 2010 at 11:35 PM
I think it would be better if you just did:

list-package

and automagically, you only got things that are valid in your context. that's a key benefit of being inside VS, rather than doing a web search ;)

this of course bears the question of whether instead of one package with multiple target platform binaries, you should have one package per platform type (i.e. one package for Moq for .NET 4, another for .NET 3.5, another for Silverlight etc.). I've been wondering this very same thing for some time now...

/kzu

--
Daniel Cazzulino | Developer Lead | MS MVP | Clarius Consulting | +1 425.329.3471


On Wed, Nov 3, 2010 at 19:05, shanselman <notifications@codeplex.com> wrote:

From: shanselman

I’m imagining a world where I’m looking at list-package returning 10,000 records. I’d like to list-package *.Web and have it just work.

Read the full discussion online.

To add a post to this discussion, reply to this email (nuget@discussions.codeplex.com)

To start a new discussion for this project, email nuget@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Nov 3, 2010 at 11:43 PM

I'm imagining a world where most of the properties needed by NuGet can be provided by the DLL itself (using reflection/shell), where packs dependencies are provided by the referenced assemblies, where the list of authors can be actualized reading the repository (CVS, SVN, Hg, Git), where a .NET SP includes all attributes to describe a project (as for example AssemblyProductSite, AssemblyProductSourceRepository ...), where the only thing to do, to add a new pack, is upload a zip, with at least one DLL file, in a win-azure site...

Perhaps my daughter of nine months is affecting me too much.

Nov 3, 2010 at 11:52 PM
where the data comes from is different from what data we need and what will be done with it.

it can be assembly attributes, an XML, fluent C#, powershell, whatever.

but we first need to decide what information we want, and for what.

/kzu

--
Daniel Cazzulino | Developer Lead | MS MVP | Clarius Consulting | +1 425.329.3471


On Wed, Nov 3, 2010 at 19:43, fabiomaulo <notifications@codeplex.com> wrote:

From: fabiomaulo

I'm imagining a world where most of the properties needed by NuGet can be provided by the DLL itself (using reflection/shell), where packs dependencies are provided by the referenced assemblies, where the list of authors can be actualized reading the repository (CVS, SVN, Hg, Git), where a .NET SP includes all attributes to describe a project (as for example AssemblyProductSite, AssemblyProductSourceRepository ...), where the only thing to do, to add a new pack, is upload a zip, with at least one DLL file, in a win-azure site...

Perhaps my daughter of nine months is affecting me too much.

Read the full discussion online.

To add a post to this discussion, reply to this email (nuget@discussions.codeplex.com)

To start a new discussion for this project, email nuget@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Editor
Nov 4, 2010 at 12:16 AM
I *get* what you’re saying, but only if the hiding of packages is perfectly smart. One mistake and I’ll never trust it again.
Nov 4, 2010 at 12:17 AM

Sure.

For example "authors" is unneeded (especially when the name of one the authors has a TYPO) because in OSS the list is too much dynamic especially now with DVCS.

Instead, what is needed is the WindowsLiveID of the uploader who has the responsibility about what was published.

Any other info that can be inferred by the assembly is error-proof

Nov 4, 2010 at 12:30 AM

Hi All,

I see that we're deciding what information we need but I think that we should start from what information we already have: the AssemblyInfo file already contains a number of fields that can be directly mapped on nuspec file items. So we should only think to which data are we missing and where to store them.

The main reason for using the AssemblyInfo, in my opinion, as a source for the information is that it is already validated by the signer of the project: In a world with 10,000 packages who can assure me that the package description matches the contained assembly?

Alessandro

Nov 4, 2010 at 12:38 AM
ghidello, we must keep in mind that .NET assemblies are not the only thing that's packaged. However, warning when the package version and assembly version (or other metadata) do not match might be a nice feature to nuget.exe.
Coordinator
Nov 4, 2010 at 12:49 AM

Keep in mind that a package is not 1 to 1 with a DLL. Some packages don't have a DLL. Consider the jQuery and jQuery.Validation package?

We could consider having the nupack.exe pack command infer some of this information if all you are packaging is a single dll by convention. That'd be fine, but that's an implementation detail of the nupack.exe command (which is used to create packages) and completely orthogonal to the original discussion that Scott is trying to bring up.

Over time, I think we definitely would like to have some way of contextualizing packages. However, in v1, we won't. And to be honest, I don't think it'll be as bad a problem in practice. Why? People don't choose packages at random. Think about the last time you incorporated a 3rd party OSS library into your project and what process you went to choose it.

I think a simple naming scheme might help and would be good enough for now.

Also, let's disambiguate the concept of "discovery" and "finding" a package. I define discovery as the process of finding a new package that solves a need. You hadn't heard about the package before. I define finding as you already know roughly what package you want, you just need to find it in our client so you can install it.

Keep in mind that List-Package is not going to be the way that people discover packages. Ruby gems has tens of thousands of packages. So their command to list gems lists the installed gems by default. We're changing List-Package to that behavior as well.

So let's imagine that List-Package -remote is going to list all packages for your current environment. If there are 10,000, was that really helpful? Can you really discover a new package via that command? How I discover a new gem (and how I imagine people will find NuGet Packages), is I go to the gallery website (rubygems.org in the gems case and we'll have a proper gallery later in our case) and I conduct a bunch of searches. Or I hear about it in a blog entry. Or on twitter.

However, List-Package is definitely a way to find packages. So after I discovered that ELMAH is the right package for me but I don't recall the exact spelling. List-Package el -remote should bring up all packages in the feed that start with "el". While it would be nice if that list was filtered for me already, it's not absolutely critical. At this point, I should already know that ELMAH will or won't work in my environment. Also, if we follow the Hanselnaming scheme, that might give me more information that's useful.

As Scott points out, we never want a false positive. We're not trying to restrict users. Maybe you know something we don't and want to install that web DLL into your Silverlight project anyways. Why should we stop you. What we want to focus on is making the common typical user scenarios nice and easy.

Nov 4, 2010 at 1:05 AM

You're right, I was only focused on .Net DLL so my message is not valid in many case.

The reason why I wrote it into this post is that I was thinking to a path for solving packages dependencies automatically (while creating a package). If people can choose any package name scheme I'll not be able to discover it starting from the assemblies my DLL depends on. But you're right on the package name purpose: let people find it easily.

Maybe we can add a new attribute called libraryName or whatever is better (As you can see english is not my first language at all and I didn't want to be rude in my last post) to be used as, let's say, DLL name.

 

Nov 4, 2010 at 1:27 PM

AssemblyTitle (summary), AssemblyDescription (description), AssemblyProduct (pack name), AssemblyCompany (link), AssemblyVersion (version)...

I'm imagining a world where what is important in a "Attribute" is it name and its propertiesNames+type instead of its concrete AssemblyQualifiedName, where you can implements an attribute named NuGetAttribute with some properties as "Tags", "ProductOption"...

It's true that in NuGet we will have packs without a single DLL... how many they will be over packs containing DLL ?

If a team/authors have decided that the name of a products is "NHibernate" (AssemblyProduct) why the NuGet-uploader have to change the pack-name. I saw a lot of problems some months ago in RubyGems where somebody have uploaded a pack named "NHibernate3" and the same with others projects.

Who represent the best source of information ? the uploader or the development-team ?

Are you sure that you want check any information of each pull-request in nupackpackages ?

I think that you have to define a convention about informations that should be contained in the DLL and leave the responsibility of its values to the team. For instance where a package is more than one DLL the AssemblyProductAttribute define the pack-name and an attribute named AssemblyProductOptionAttribute may define an option inside the same pack. As example:

[assembly: AssemblyTitleAttribute("NHibernate.ByteCode.Castle")] [assembly: AssemblyProductAttribute("NHibernate")]

[assembly: AssemblyProductOptionAttribute("Castle")]

Let the development-team to define/develop which are their options, then you can reflect the DLL to discover which are the pack-dependencies of the new option.

Somebody may upload a fake DLL, a "Report as abuse" would be useful and with a list of trusted users (perhaps generated from committers names) may be you can manage fake-packages easily.

Where a package is not a DLL the actual method, perhaps, is the only way to walk.

P.S. I did not write "IMO" or "IMHO" everywhere only because when I'm the writer I can't do anything else than write my opinions.