Chocolatey-coreteampackages: Usage of PowerShell aliases in Chocolatey Installation Scripts

[gep13]

This topic has come up again, and I think that we need to discuss it again....

The main part of the recent discussion takes place in this PR, I would ask everyone who is interested take a read of that thread, and then come back here.

For me, the interesting take away from that discussion was this:

Besides all that I said here, making ALL packages here non-aliased and pushing fix version is basically trivial (expand aliases recursively and force update ), because we have a good system in place.

I totally agree with this, and assuming that we can all agree that going forward, we stop using aliases in Chocolatey Install scripts, then I think at some point, we should go back and do just this.

This repository is run by a set of volunteers, and I think that it makes sense to vote on the topic, so I would ask you all to edit this comment (if you don't have access rights to do that then let me know), and we will see where we all stand.

For removing, and stopping, the usage of aliases in Chocolatey Installation scripts:

• @gep13
• @jberezanski
• @pauby
• [insert name here]

For removing all aliases that aren't readonly and descriptive, and stopping, the usage of those aliases in Chocolatey Installation scripts:

• @AdmiringWorm
• [insert name here]

Against removing, and stopping, the usage of aliases in Chocolatey Installation scripts:

• [insert name here]

[AdmiringWorm]

I've added a third option that I think is appropriate, removing aliases that isn't read-only, and only to allow the use of read-only labels.

I've actually made a list of those read-only aliases in a gist (checked on POSH v2):
https://gist.github.com/AdmiringWorm/4f576301250313f862135542464516ed

EDIT:
Changed it again to only be for readonly and descriptive aliases

[jberezanski]

I'm all for banning aliases indiscriminately. That's how my team develops at work and I like the readability increase very much. And, after writing PowerShell that way for years, code with aliases simply looks ugly to me - in part due to the contrast between aliases and full cmdlet names.

Segregating aliases into categories and banning only some of them would, in my opinion, make it harder to review code, because the reviewer would have to memorize the allowed alias list or consult it often - time and mental effort would be wasted instead of spent on analyzing the actual behavior of the code.

[majkinetor]

I don't think we need to discuss this. Its artificial question brought by someone who isn't maintainer here and to present an illusion that something constructively is done here, while the reality is just the opposite - it is arrogant behavior to come to something that somebody else made and requesting a change while having almost 0 contribution in any aspect of it. The vote must be earned.

So nah, I am against removing default aliases unless we have a real problem with them and we don't so far. Furthermore, if you keep insisting, you are gonna take from me the most important fun part and reason I develop - a freedom of expression - which will surely mean that my contributions here will drop to minimum. If you think that is a fair trade, by all means go that route.

[gep13]

Furthermore, if you keep insisting, you are gonna take from me the most important fun part and reason I develop - a freedom of expression - which will surely mean that my contributions here will drop to minimum. If you think that is a fair trade, by all means go that route.

@majkinetor so just so we are clear, what you are saying is... "do things my way, or I am not going to contribute"? And you said that @pauby was being arrogant! To me, the statement that you have just came out with is one of the most arrogant things I have ever heard.

[majkinetor]

Your interpretation is wrong. I said i wont contribute to something I dont enjoy. Its a personal thing, not a blackmail as you present it to be.

one of the most arrogant things I have ever heard.

Lol. You must have been living in the cave then, if THAT is the most arogant thing you ever heard.

But OK. Feel free to ban aliases. That contribution probably changes things dramatically, I just need some time to let it sink in 😐...

[ferventcoder]

I am a strong believer in strong opinions weakly held. I'll start out with a couple of questions:

• If we can make PowerShell code that is less prone to breakages AND also easier for even novices to read and understand, why wouldn't we do that?
• What if folks could continue to write the code with aliases and the code was cleaned up to allow for that maximum compatibility and readability later?

Facts

• ScriptAnalyzer fails on validation for Aliases - discussed on #743 which was closed for inactivity
• Microsoft PowerShell community advises against aliases for shared scripts - https://blogs.technet.microsoft.com/heyscriptingguy/2012/04/21/when-you-should-use-powershell-aliases/ is a great article talking about pitfalls you can run into
• The use of aliases has resulted in broken packages in the past. So this repository has had packages that have fallen into some of the pitfalls described in the previous article.
• The Chocolatey community has a very diverse set of skills in folks using community packages, many of which have zero or very limited experience with PowerShell.

Opinions

• Alias use makes things hard to read and decipher.
• Some folks enjoy using aliases and it makes coding enjoyable for them.
• If the package scripts are hard to read, they may be hard to trust.

Future Thoughts

• PowerShell v6 may have removed some aliases for Linux side.
• Supporting POSIX environment usage with PowerShell and what that means here

My Interpretation

As you know, my opinion is to always make things more approachable, even if it is a bit more work on my end. It's easy to write code, it's much harder to write code that others can understand. Chocolatey didn't get to where it is today because I made a point of making things harder to understand or did only parts of it I enjoyed. No, I documented and rewrote code from working into code that is optimized for humans.

Yes, maybe it is easier to write with aliases, maybe even fun, but at what expense? In the end we should be teaching folks the best way to do things with the code that we produce as a side effect of what we are doing with packaging. Lots of folks learn PowerShell because of Chocolatey, and IMHO we should be showing them best practices. I get we don't always agree with best practices, but having a good reason for that divergence is important.

If people can't understand the code, it makes it harder for them to trust running it on their systems. If we can make the code less prone to breakages plus easier for them to read and understand, why wouldn't we want to go that route?

I actually prefer some aliases, such as % and ? in shared code. I'm not sure if they make things less readable. I think when most people talk about aliases, they are thinking gci,ls, etc. Even my preferred aliases are likely subject to the question above though.

Question

And I'll leave with a question - what if folks could continue to write the code with aliases and the code was cleaned up to allow for that maximum compatibility and readability later? Would you be against that?

[ferventcoder]

And FYI, I had not read @pauby and @majkinetor 's discussion until after I wrote the above. I see overlap now that I read the other.

[majkinetor]

@ferventcoder that is great idea. Those who want this can create AU plugin to make alias expansion before packing.

[majkinetor]

Closing this. If you feel there is more to discuss feel free to reopen.

[majkinetor]

Anything more to discuss @pauby ? Reopening silently doesn't really count.

AU plugin is perfect solution for this and fairly trivial one to create.

Arguments so far are related to regular shell usage and ignore context, and are thus invalid - choco uses integrated shell so any alias customizations do not propagate. Some other arguments are also not related as they involve version compatibility or other things that clearly violate guidances.

[pauby]

I actually spent about half an hour writing a response to this comment but I deleted it. I couldn't actually be honest without it coming across as rude or finger pointing both of which are unnecessary. So I deleted it all.

I've actually said everything I have to say on this. I thnk everybody knows my views. I've not heard a valid argument as to why you would use aliases.

I tried to get involved in this repo especially after reading the contribution guidelines around code (it stated that non-readonly aliases shouldn't be used) but when I got involved in the original thread instead of working towards a solution the guidelines were changed to favour @majkinetor 'coding style' (as he stated it was). I can't support this type of working and I'm not putting my name to it. And it's also the reason my time in the repo was short lived. I would like to have been more involved in here as there is a lot happening and things to get my teeth into. Both @majkinetor and @AdmiringWorm have done great things with it and has changed a lot since I first started using Chocolatey (a long time ago now).

My concern is for the Chocolatey brand and project. I'm proud of being a moderator but I've largely backed off from being involved due to all of this. I'm tired of the sniping. I'm tired of the snide comments being made. I'm tired of the disrespect that's evident. I'm incredibly disappointed that this is where we are but I do hope it can change.

[pauby]

@majkinetor The system PowerShell host can be used with Chocolatey. But that's besides the point. @ferventcoder makes points beyond technical ones that I've tried to highlight myself previously.

[pauby]

And I'll leave with a question - what if folks could continue to write the code with aliases and the code was cleaned up to allow for that maximum compatibility and readability later? Would you be against that?

@ferventcoder I actually suggested that:

Besides all that I said here, making ALL packages here non-aliased and pushing fix version is basically trivial (expand aliases recursively and force update ), because we have a good system in place.

That's not what I was suggesting - what I was suggesting is amending packages as we go along. But if it's trivial to do all packages then that's a win win. However pushing 200+ packages into the queue at one time would be a bad idea as it's going to create a backlog. I would suggest it would be better to update the files that are needed and then have them push the changed files on the next natural push update?

I think as it's trivial to amend them then they should be, perhaps in batches rather than one mass submission.

[majkinetor]

What is the problem with AU plugin idea ? Its basically Expand-Alias in a loop prior to cpack, everybody happy. That is the least intrusive solution that also shifts the job on those who do have a problem.

It currently has to run in BeforeEach block tho, until https://github.com/majkinetor/au/issues/116 is done, but that issue is just syntax sugar to what we have now. I am more then happy to assist you or anybody else in creating it.

The guidelines were changed to favour @majkinetor 'coding style'

While majkinetor makes majority of contributions here, its imperative that he is as efficient as possible (the same for @AdmiringWorm) given that we maintain this project for free. When that is not the case, then I will be happy to accept basically any standard from prominent contributors. To make you understand how much job was to make AU and core team repo on this level during previous year, realize that it required engagement that is like another job (both in time and effort) after my real life job.

I would like to have been more involved in here as there is a lot happening and things to get my teeth into.

I would like that too. I am not the type of person that holds a grudge. Perhaps you can let this one go for a moment and contribute in other areas ? 🤝

[ferventcoder]

What is the problem with AU plugin idea ? Its basically Expand-Alias in a loop prior to cpack, everybody happy. That is the least intrusive solution that also shifts the job on those who do have a problem.

Apologies if there was confusion on this. I completely agree with you, but I do want the code IN SOURCE to be as close as possible to the code that is deployed. That means the AU plugin would expand and check in, not just cpack.

[ferventcoder]

Consider that if we are to ever get Microsoft to sign off on Chocolatey more so, we do need to stop using aliases. They don't support it, so if the PowerShell team comes in here and sees us going against their guidance, I highly doubt they are going to get behind it. Worse, they may decide that we are too far off to be fixed and start looking to build alternatives. Right now, we do have validation and blessings of folks from Microsoft. I don't think we should continue to do things that could disrupt that.

[pauby]

If nobody has anything else to add can we get a definitive decision on which way to go on this? @ferventcoder

[ferventcoder]

Here is what I believe we decided on:

• In package creation, aliases are fine and allows folks like @majkinetor to move quickly in getting things setup.
• Someone will need to develop an AU plugin that will run Expand-Alias and make that part of the commit back with the other updates to the packaging.
• The committed code will then match the packaging that was released
• During maintenance, typically those sections of code would not need to be rewritten.

The code meets the guidelines set forth and allows for easy development. It's hard not to see a win/win.

[AdmiringWorm]

all new package versions should from now on have all their aliases expanded automatically (only scripts in the tools folder) when they are updated.
As such I'm closing this issue.

[majkinetor]

Can it be made to work without expanding % and ?

[pauby]

As an aside to this, as we appear to be at the end of this, I wanted to add this for reference:
From this thread:

"While controversial, our stance on aliases has been pretty clear over the last few years: namely, that they're almost purely for interactive usage, that they shouldn't and can't be used to provide truly deterministic behavior in scripts/modules shared outside of your personal usage, and that you should add aliases as appropriate to your profiles or within module scope if you want them."

@majkinetor My view is we expand all aliases rather than cherry-picking.

[AdmiringWorm]

Can it be made to work without expanding % and ?

Not currently, but if you wish you can open an issue regarding this over at https://github.com/WormieCorp/Wormies-AU-Helpers/issues I'll see if I can't provide an ability to pass in a whitelist of aliases to not expand.

However, I'm with @pauby on this one, I see no reason to cherry-pick the aliases, but I can still provide an option to do so.

[majkinetor]

I would like to have been more involved in here as there is a lot happening and things to get my teeth into.

Great contributions so far m8.

[pauby]

I'm not sure I understand Milo. Can you elaborate?

On Wed, 11 Apr 2018, 16:01 Miodrag Milić, [e-mail] wrote:

I would like to have been more involved in here as there is a lot
happening and things to get my teeth into.

Great contributions so far m8.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/chocolatey/chocolatey-coreteampackages/issues/913#issuecomment-380484426,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMK2y9Kes02ONJ1Vi70zfJZR9Vam2BTYks5tnhrEgaJpZM4QiomK
.