Camping..?
No not that thing with tents. Or in games like Gears of War, Call of Duty or other First Person Shooters, especially in online multiplayer matches, which I used to not only really enjoy after a long hard day, I also was really good at. This was what lead me to my gamertag (kilasuit), and especially in match types that required a team to work together, whether that be Capture the Flag or Search & Destroy etc, especially if I managed to get team matches where I could play with my a number of my friends or my cousin and a few others & we as a group did do really well as we coordinated each other well.
Though these days, I don’t really have the time for playing those kinds of games that much. I also really don’t like how games have been ruined/en💩ified by dulling down teh trashtalking in them.
Maybe that’ll change in the future, who knows. However I played back before there was this craze of reporting people for trash talking and that was actually one of the more fun parts of playing. Knowing that when you’d no-scoped headshot someone you were gonna get some form of abuse for it. But perhaps that’s because much of my generation, takes that sort of thing as it should be, as just a little bit of gaming banter. What ruined this was so many people Swatting others which then required providers like Microsoft & Playstation to not only introduce more Safer play controls like reporting players but to double down on existing ones and add AI for content screening in messages, which is sad that just a few ruined gameplay for those of us that could take annoyed/rude/provocative/threatening messages or voice notes & counter them in such a way that most of the time we actually ended up becoming online friends and would chat to each other & even team up together. That is something that I strongly believe all gamers (& others) need to work on, and come together and have fun but not go too far with the Trash Talk but also, learn to take it on the chin a bit, especially as many people game to release other built up personal stresses. I mean, I know all about the Power of Swearing - mhasl.me & the health benefits it brings us.
Sometimes a simple follow up a day/two later, with hope your having a better day than when you sent me .... actually goes a long way into the other person having a rethink and apologising to you for it. This is something that isn’t just limited to gaming circles, as I’ve seen it in every single type of social circle I’ve been in & I’ve been in many in my life.
It would be nice, as someone that really can take what gets thrown at me, if I could mark my online accounts as allowing all trash talk and instead of AI Monitoring of of player to player content we could have a surveillance-free session again. Though that I feel requires us gamers hosting our own game servers or playing together in person in LAN Matches like we did in 90’s & 00’s.
Anyway sorry for the long camping bit (though I hope to get back to both kinds of camping at some point) and lets get into what this is meant to be about.
Background
@StartAutomating said in the PowerShell Discord (https://aka.ms/psdiscord) in #bridge channel
that one isn't public, either 🙁 I don't think a private unlisted module should be able to "camp" a name.
Note if you usually use Slack for the PowerShell perhaps because you can’t use Discord in your organisation this is now back up and running. To join you can visit https://aka.ms/psslack - Thanks to @Jaykul for running this resource and for spending the time to get this working again recently.
Unfortunately, its been this way with package registries since they were invented, mostly because we are lazy and want the shortest path, also why pwsh was chosen over powershell for the executable as it wasn’t already in use on linux package registries systems like apt etc, & no one really wanted to have to type powershell anymore.
I also do not see this changing for global public package registries but can see this being something that changes when you start adding a registry of registries to tooling like ‘PSResourceGet` or ‘Nuget’ or npm pip or other package managers.
Note this was a requirement to enable user/admin preferred installation sources, in PowerShellGet v3’s RFC - and was what lead to PSResourceGet. This was required to continue & more easily enable
inner sourcingas well as cross organisational sourcing (as opposed to global sourcing) in PowerShell.
We like being lazy
Ok so it’s a general consensus that most IT people & not just devs, but they can be really bad for this, in that they can like being what many call lazy, whereas many (myself included) would argue laziness to some, is, being highly efficient to others which whilst mostly true, does require a certain amount of prior knowledge to get to that ability.
Laziness has trade offs, like readability in code, maintainability, searchability, accessibility, and so forth. That’s why PowerShell is a versatile language that caters for being lazy/efficient (also known as terse) as well as being able to be more verbose and use the full command and parameter names in scripts and module.
PowerShell, gets a lot of hate for this. Mostly from those in the Linux Space that are used to incredibly terse & can to many be cryptic codebases. Minified JavaScript is an example of a language (as is all other minified languages) that really makes it difficult for me & many others to properly troubleshoot things.
Laziness can bring security & reliability issues
Developers, if given the chance, will as part of their build, test and release pipeline will regularly mark to use latest for a package.
This can be both a security and a reliability concern, if pulling from a public source without doing due diligence around reading release notes or checking if a release introduced a breaking change, whether purposely or accidentally due to reliance on a downstream package.
This is why many in the industry, myself included, recommend using version pinning. A recent example of this is in Obsidian - Less is safer: how Obsidian reduces the risk of supply chain attacks where they call out good security practices like Version Pinning & Inner Sourcing (where allowed), both being industry recommendations.
There is plenty of tooling around to help you with inner sourcing, including installing packages into your own feeds. It isn’t hard, but is yet another thing that requires time & effort.
Please if you have the resources & skills to do this, as a package author, please do so with publishing to your own public & ideally private network isolated feeds as well as any global feeds as part of your release process. It’s additional steps, but allows your stuff to be downloadable if a global feed goes offline, or worse if you are isolated from the internet at all.
This is also why I personally prefer having a build/test/release process that I can do 100% offline. As there are times where I either have no internet or purposely turn it off as part of deeper focus time as this helps me 🔗Finding the Balance: Technology & Mental Health - mhasl.me - Mental Health Affects Someone Like Me🔗 which is something I know at times we all need to do.
Names aren’t a unique enough identifier
I mean we all know this from our own names. What makes us unique is our experiences. Which you could class as additional metadata about us as individuals.
However that aside, every single package feed has other metadata that should be used as a way for unique identification of a package. Author, Company Name, Version etc are just a few. Installation processes should realistically require you to provide more than just a package name. Especially as if any of these additional bits of metadata change, you should do a package review to determine if the package is still suitable to use and has not been republished by a malicious actor.
Also why it’s strongly recommended in many package registries to namespace packages which makes the package name much longer or install from other public feeds, like ones we as publishers should in future maintain, as opposed to reliance on a global public feed. Which is why in the Nuget.org package feed we have System. & Microsoft. Prefixed Packages & also why we are seeing more of this in the PowerShellGallery which is only a good thing.
An Example Namespace for some of my previous packages could be kilasuit.ARMTemplateComplexity if I use the kilasuit prefix for namespacing or any future one that I decide, as long as it’s supported in the global package providers that is.
But that said it’s also why the PowerShell Module Manifest has a GUID field as way to uniquely identify modules (even though this isn’t used in the engine) - though that was broken in the PowerShell EcoSystem as there was some tooling in the community that was using the same guid for each new module that was created with it & lots of modules were created with it. Which has since been fixed, however modules with that same guid are still able to be found today. Damage was done and it may not be recoverable without a major purge of modules. Or instead creating another way to uniquely Identify Packages that isn’t just a name.
Platform Package IDs
Microsoft are also moving to hosting things in the Microsoft Artifact Registry, which is a form of trustable multiple package type feed. Others will likely host their own similar feeds for all types of packages in future which is why I’ve asked for Add a process to manage and query a Registry of Registries to allow Module Authors to publish to their own sources as this would allow Module Authors who want to have short module names to do so.
However, truth be told this is actually a flaw in how the Gallery performs validation of a package and dumps the resulting package information in to the backend database that the gallery is pulling that data from when you query it.
It’s also why PSResourceGet allows for package feed priorities & was part of the requirements for it under the PowerShellGet 3.0 RFC.
It’s also why it’s a pain when packages get renamed or deprecated (Azure PowerShell & PowerShellGet being great examples) and there isn’t a simple alert to the user to instead install a different recommended package over the one that they are trying to install. There could be, if something like 🔗Add Suggestion information when Modules are renamed or deprecated due to authors moving onto other work🔗 actually were to happen.
Though in future I hope this can be managed for module authors in such a way that they don’t need to make a [Proxy Module] as whilst this can be useful for large organisations like Microsoft, it’s a large amount of work that others are unlikely to undertake. I know I wouldn’t, even if it may be less of a breaking change to others. But that’s because my modules aren’t (from what I can tell) all that well used, unless you of course are including those I’ve helped with over the years but am not a core maintainer of, or am moving away from maintaining as I don’t have the time for them anymore.
I have previously tried to get devs to be less lazy in the right places but as always get met with resistance. This is why (not just because I was shouty about it) but the community ended up building projects like Module Builder & other similar projects as to help authors of modules add metadata that improves the overall experience, particularly in discoverability and engine performance.
How can you solve this…?
Well in the global package feeds you can publish using a namespace, and to whatever other feeds you want you can publish your shortened versions.
This is a small amount of additional work.
This also helps in identifying the Where'd this come from question that you may have when asking from troubleshooting issues.
It is however a plaster over another issue.
That we are lazy, and unfortunately becoming lazier thanks to the supposed golden age of AI, which well, I ain’t a fan of either the messaging or the potential outcomes of lost jobs particularly the lack of junior roles. But then again I know my roots.