The really short aliases

Oct 3, 2010 at 7:42 PM

I've been thinking about the really short aliases we added (nap, nup, nrp, etc.). They seem like the sort of thing we should leave to the user's PowerShell profile, rather than us defining them. I feel like we should remove them. Thoughts?

Oct 3, 2010 at 7:52 PM
I personlly like having the aliases in the box.  I really try to avoid profile settings, mostly because I use a bunch of machines and I hate having to sync profile settings
Coordinator
Oct 3, 2010 at 8:04 PM

At the very least, we shouldn’t put them in the main script, right? What if you want to customize them because they conflict with some aliases you’ve already defined?

Editor
Oct 3, 2010 at 9:21 PM
"nup" is no more likely to conflict than "install-package." Just check if they have it already aliased first.

+1 for out of the box
>
Oct 3, 2010 at 10:09 PM

I didn't mention this because I was worried about conflicts; that's easily handled in the profile script anyway. I mentioned it because our short aliases weren't what I personally liked and felt was intuitive, so I already started aliasing them to what makes sense *to me* in my profile, and this made me think that perhaps other people would have their own ideas about what made a good terse alias. Of course, they can always remove the aliases we add, or just ignore them, but I wanted to mentioned this in case other folks felt like it was one of those features that doesn't add much value and is bloat that can be removed. It sounds like at least a couple of other folks like it out of the box, so maybe I'm just being silly.

Oct 3, 2010 at 11:18 PM

Just out of curiosity, what aliases do you use?

Oct 3, 2010 at 11:26 PM

inpak, uppak, unpak, lspak

Oct 4, 2010 at 12:41 AM

I liked having aliases when we were using add/remove, because that prefix was too common.  e.g. you'd type 'rem' TAB, and you'd have to go down 7 or 8 times to find remove-package.  If we switch to the install/uninstall, that issue mostly disappears since there are no existing commands using those prefixes.  So I probably would not use the aliases anymore.

As an aside, the fact that there are no existing Install/Uninstall commands makes our finding that they are 'valid' verbs slightly suspicious ;)

Oct 4, 2010 at 7:07 PM

Fret not, 'install' and 'uninstall' are definitely valid/approved verbs.

Here's how I found out. I'm currently porting all the cmdlets to managed code. When I first tested the console after my change, PS displays a red warning message about 'List' being an invalid verb. It didn't warn about Install and Uninstall, however.

Of course, I'm not sure why there are no existing Install/Uninstall commands. Perhaps all the built-in cmdlets make more sense with 'Add/Remove'.

Coordinator
Oct 4, 2010 at 7:23 PM

There’s probably not a whole lot of package manager or installation commandlets. J

Oct 4, 2010 at 8:20 PM

Awesome. It's great news from intellisense point of view that we'll have the only commands with those prefixes.  So I don't think I'll personally use aliases for them, so I don't feel strongly about them.

Oct 6, 2010 at 8:50 PM
Edited Oct 6, 2010 at 9:00 PM

Just my 0.02c:

Over the last couple of years, it's been generally a thing with powershell snapins (and now modules) that aliases are typically best left as an optional import for the user where possible. As has been said on this conversation so far, aliases [that are not not shipped with the shell] are often created by users for their own use. Production scripts should not depend on aliases; fully qualified commands should be preferred at all times. As you have taken a dependency on PowerShell 2.0, you should encapsulate your functions and cmdlets in a "NuPack" module, and allow optional exporting of aliases.

As regards List as being a non-standard verb, this is correct. The correct verb for enumerating items should be "Get," and the Cmdlet should be using the well-known "Get" verb partner of "Name" as the primary parameter. Additionally, strongly consider accepting wildcards such as * for partial matches. If you guys are more comfortable internally with using the current "Id," I would suggest you use a parameter alias for "Id" and rename the parameter actual to "Name."

All other qualms aside, I love the functionality exposed so far, this is seriously great work guys - very impressive. I'll kick the tires for a couple of days and create a new thread with any suggestions for improvements or guidelines I can offer. I notice that you have not gotten around yet to designing your Cmdlets/Functions for composition ( e.g. get-package nhibernate -version 1.1 | add-package ) and also support for -WhatIf to allow the user to see what packages and dependencies _would_ be installed; I can help here too.

-Oisin G.
PowerShell MVP
( pscx.codeplex.com pseventing.codplex.com psprovider.codeplex.com psstudio.codeplex.com pssharepoint.codeplex.com psmobile.codeplex.com ... )

Oct 6, 2010 at 9:13 PM

Regarding Cmdlets comosition, the reasons that command doesn't work is that the get-package cmdlet doesn't support a -Name parameter (yet). Once that is implemented, it will work, because the add-package cmdlet does accept pipeline values for its parameters.

Also, supporting -WhatIf is on our radar.

Oct 6, 2010 at 9:15 PM

We even have an issue open for -WhatIf support. It's slated for vNext though.

Oct 6, 2010 at 9:18 PM
Cool. Sounds good - if you need to bounce anything off me, send me a message.
 
First thing you should probably focus on is moving your script into a powershell 2.0 module instead of a standard ps1. This will allow you to hide implementation details and private functions.
 
-Oisin

On Thu, Oct 7, 2010 at 12:15 AM, dotnetjunky <notifications@codeplex.com> wrote:

From: dotnetjunky

We even have an issue open for -WhatIf support. It's slated for vNext though.

Read the full discussion online.

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

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

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe 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




--

---
404 signature missing
Oct 6, 2010 at 9:22 PM
I knew we should have had a PowerShell MVP working on this instead of a SharePoint one. Great suggestions and ideas.

This message was sent via Blackberry.


From: oisin <notifications@codeplex.com>
To: Simser, Bil
Sent: Wed Oct 06 15:19:05 2010
Subject: Re: The really short aliases [nupack:229465]

From: oisin

Cool. Sounds good - if you need to bounce anything off me, send me a message.
 
First thing you should probably focus on is moving your script into a powershell 2.0 module instead of a standard ps1. This will allow you to hide implementation details and private functions.
 
-Oisin

On Thu, Oct 7, 2010 at 12:15 AM, dotnetjunky <notifications@codeplex.com> wrote:

From: dotnetjunky

We even have an issue open for -WhatIf support. It's slated for vNext though.

Read the full discussion online.

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

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

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe 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




--

---
404 signature missing
Oct 6, 2010 at 9:22 PM

Yes, I actually ported the cmdlets to managed code just two days ago in the main branch. The ps1 file is quite clean now, with mostly the functions to support tab expansions.

I'll look for your feedback when I am doing anything major to PS cmdlets/functions.

Oct 6, 2010 at 9:37 PM

If the ps1 is now considered "clean," all you need to do is rename the ps1 file to .psm1 and it's done. Add the foot of your script, use Export-ModuleMember -Function foo,bar -Cmdlet foo,bar to opt-in to export. Anything omitted from here is considered "private" but is still in scope for exported functions/cmdlets to reference/call. Leaving out the Export-ModuleMember will cause all commands (functions/cmdlets) to be exported, polluting the console with implementation details. Don't feel too compelled to create Cmdlets out of all your functions - sometimes it's easier to keep prototypes as script until you're happy with the API. Functions using CmdletBinding are almost on parity with native Cmdlets (some scoping quirks) so you have nothing to lose really. Have fun!

Coordinator
Oct 6, 2010 at 10:11 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Coordinator
Oct 6, 2010 at 10:12 PM

Created a work item for this. Thanks!: http://nupack.codeplex.com/workitem/181