Adding a new cmdlet.

Mar 24, 2011 at 8:06 AM

We are adding a new cmdlet in the nuget console to open a package's project url, as specified by the ProjectUrl attribute in the .nuspec file. (see http://nuget.codeplex.com/workitem/823)

I'm thinking of the following names:

  1. Open-PackageProjectPage
  2. Open-PackagePage
  3. Show-PackageProjectPage
  4. Show-PackagePage

In all cases, the cmdlet will accept an Id parameter which specifies the package name, and an optional Source parameter to specify the package source. If Source is not specified, it uses the selected one from the dropdown box.

I like (1) the most but I admit that it's a bit verbose. Which one do you prefer? Or feel free to suggest a better name.

Coordinator
Mar 24, 2011 at 4:23 PM

I kind of like #4. “Show” is more descriptive. I assume it’s a valid PS verb or you wouldn’t have suggested it, right? J

Mar 24, 2011 at 4:52 PM

yes, it's valid.

Mar 24, 2011 at 5:15 PM

I'd like to add Get|Show-PackageSite for consideration. Alternatively, if a package doesn't have a site, it might be nice to keep Get|Show-PackagePage, and allow it to specify a file to show within the package (like a README or a help index).

Another idea is Get|Show-PackageHome.

Mar 24, 2011 at 5:19 PM

I prefer Open to Show, because Show means only printing the url to the console. Open actually opens the webpage.

Mar 24, 2011 at 5:57 PM

I prefer #1 - Open is in more common use for web pages, no? You open web sites, open web pages.

-Oisin

Mar 24, 2011 at 6:01 PM

Sorry, I meant Open|Show- above, not Get|Show above.

Coordinator
Mar 24, 2011 at 6:05 PM

I’m convinced. I retract my earlier vote and now vote for #1. J

Mar 24, 2011 at 6:10 PM

I still don't like Page, but of those options, I like #1 as well.

Mar 24, 2011 at 8:20 PM
I think I'm a fan of Url because we don't really know if we are going to a page or a site, and rather than argue over those (I prefer site because it could have multiple pages - we are really navigating to a page on a site - but from the user perspective I want to go to the site).

Anyway, Url tells me exactly what the behavior is going to be. I know it's going to open in a web browser. Page and Site are too overloaded, IME.

So my vote is for:

Open-PackageUrl

unless we are going with more stuff later
like

Open-PackageNuGetUrl
Open-PackageHelpUrl
Open-PackageLicenseUrl
Open-PackageProjectUrl
Open-PackageDocsUrl

then it's for : Open-PackageProjectUrl (where we spell out this url is for the project)
Coordinator
Mar 24, 2011 at 8:43 PM

Mmm, good point. How about

Open-PackageUrl

And if we decide to support others later:

Open-PackageUrl -License

Open-PackageUrl -Help

Open-PackageUrl -Project //Default so not needed

Open-PackageUrl -Docs

Mar 24, 2011 at 9:06 PM

The problem with Url is that it's not always a url. If we decide in the future to embed license text inside the package, it's not a url anymore.

Mar 24, 2011 at 9:08 PM
A url can be to a file. You can open a file in a web browser as well, even if it's local. :D
Coordinator
Mar 24, 2011 at 9:11 PM

He meant, what if it’s embedded in the nuspec. Then there’s no file to open.

Mar 24, 2011 at 9:15 PM

I think we should stay away from being specifc about what and where the content comes from. Whether you are going to a page or a site shouldn't matter.

Mar 24, 2011 at 9:17 PM
IMHO that would be too much noise inside a spec file. I would prefer it to be it's own file that gets packaged in.

That could be pulled out and displayed it if someone asked for it. :D

Mar 24, 2011 at 9:18 PM
So are we back to Show|Open-PackagePage?

Show to me would mean we are going to try to display it inside the console. Open means we are going somewhere.
Mar 24, 2011 at 9:24 PM

Yup, that's what I said earlier. I prefer Open too.

So, I think the name will be: Open-PackagePage. Then we have:

Open-PackagePage -License

Open-PackagePage -Help

Open-PackagePage -Project //Default so not needed

Open-PackagePage -Docs

 

 

Coordinator
Mar 24, 2011 at 9:25 PM

I agree. Page is generic enough it could mean anything. J A page is also an abstract concept. Let’s just do this and move on. J

Mar 24, 2011 at 9:49 PM
Good enough for me. +1