Moving Evergreen to a single Get function

[aaronparker]

Evergreen currently consists of a function per application which isn't consistent with other solution's approaches (e.g. Choclately, winget etc.). Some time in 2021, we'll move Evergreen to a single function; however, there are a number of considerations for this and decisions that need to be made.

This discussion will be updated as required and the status of this work can be tracked here: Consolidate Get functions into a single function.

• Determine the name of the single function - e.g. Get-Evergreen. This might work like this: Get-Evergreen -AppName AdobeAcrobatReaderDC
• Enable search functionality to make the list of supported applications discoverable - this could be a function of Get-Evergreen or its own function e.g. Search-Evergreen
• Exporting the current app/function manifest info is done with Export-EvergreenFunctionStrings. This should likely change and could become a function of Get-Evergreen or remain its own function by renaming Export-EvergreenFunctionStrings to something simpler (e.g. Get-EvergreenManifest -AppName AdobeAcrobatReaderDC)
• Manifests need to be updated to separately list vendor and application name to make searching and listing packages easier. Manifests should likely follow the format used by winget with Vendor.ApplicationName
• Some functions include parameters (e.g. Firefox includes a parameter for languages) - moving to a single Get-Evergreen function will require removing the parameters. For example, Firefox would output downloads for all languages requiring filtering of the output with Where-Object

[haavarstein]

Thanks Aaron, that a fantastic idea and a great evolution of the Evergreen framework. I've been playing a ton lately with the various solutions, and it have become even clearer that Vendor Update API is the only way to go. I don't like the moderated solutions, but I use them as a backup in case the app isn't available in the Evergreen module.

Now for the commands I like the WinGet approach (not the YAML though!). With the Show command below I get ALL the details I really need. Vendor, Product, Version, URL, Switches and Description (used for Intune Win32App creation). There are even more like Home and License URL in case you want to include those in Win32App.

Show package information:

winget show winscp
Search-Evergreen winscp

Download Source only:
Get-Evergreen winscp

Install:
Install-Evergreen winscp

The only thing I can think about that we should add to the manifest would be a PNG image for Win32App creation. Choco have that.

[littletoyrobots]

Perhaps a -ListAll switch as well?

[BronsonMagnan]

I love this idea Aaron. For multi-culture downloads like Firefox, you could consider a default culture. For the search functionality, I agree with your assessment, however including a vendor's description in the output object would by useful.

[haavarstein]

At least add Description to the manifest file as optional. I'm updating my private XML file as we speak using Google / Wiki results as description.

[JimMoyle]

I love the vendor.appname syntax.
Search-Evergreen is good
I like Get-EvergreenManifest, in fact I like Verb-EvergreenNoun
You could add a -Filter param that works with wildcards or maybe regex

[haavarstein]

Mine too

[rweijnen]

Agree as well on Get-EverGreenApp

[msfreaks]

I'm not familiar with the vendor.appname syntax (other products?), but would that mess up application names like Node.JS or Draw.io?
What if the vendor also has a . in its name?

[aaronparker]

winget uses this notation: https://github.com/microsoft/winget-pkgs/tree/master/manifests

[msfreaks]

aha! to me that's \vendor\appname :)

[msfreaks]

Great idea!

I can provide my library of 100x100px PNG icons for about 160 apps if needed

[aaronparker]

I've also got a repository of icons maintained here: https://github.com/Insentra/intune-icons

[briantimp]

I love the idea and can follow Erik's suggestion:

Search-Evergreen winscp
Get-Evergreen winscp
Install-Evergreen winscp

[aaronparker]

I don't really want to be taking on an Install-Evergreen. The intention isn't to complete with Choclatey or winget and most enterprises are likely to have more complex install and configuration requirements. Install commands included in the manifest at the moment are really a best effort.

[Robert-LTH]

Instead of an install command it would be nice with a command which can produce a certain type of package.

Get-EvergreenApp -AppName Firefox | Out-PSADT -Destination C:\Repo\Firefox\version
Get-EvergreenApp -AppName Firefox | Out-Winget -Destination C:\Repo\Firefox\version

[JonathanPitre]

I agree with you @aaronparker about the install-evergreen command, Evergreen was not design to replace Chocolatey or AppDeployToolKit.
For people who wish to install apps via powershell I suggest you look at my psadt module instead.
https://www.powershellgallery.com/packages/PSADT

Get-EverGreenApp -Name has my vote, keep it simple stupid!

[RMITBLOG]

This is a great Idea, Arron.

Get Evergreen application

"Get-AdobeAcrobatProDC" is a bit messy, moving to "Get-Evergreen -AppName AdobeAcrobatReaderDC" or "Get-EverGreenApp -App Name AdobeAcrobatReaderDC" would offer a better scripting experience in my opinion. If we are referring to packages like MSIX or APPV you could use "Get-EvergreenPkg - App name"

Changing from export to get-EvergreenManifest

Changing "Export-EvergreenFunctionStrings" to "Get-EvergreenPKG -AppManifiest AdobeAcrobatReaderDC" or "Get-EvergreenPKG -AppName AdobeAcrobatReaderDC -AppManifiest"

[rweijnen]

I'd suggest Get-EverGreenApp -Name rather than Get-EverGreenApp -AppName or Get-EverGreenApp -App as -Name describes it well and is a very common parameter name. Also easier with accepting pipeline input (although you can of course use alias for that)

[jaywv6299]

I think Evergreen is great, I incorporated it into our Virtual Desktop update process. A list of apps supported would make it more useful for our organization.

How about adding a destination for the update? I support both Virtual and physical desktops. Having the first download go to a central repository and then pulling from that central repository would limit internet downloads. Specifically because some of the virtual desktops are not allowed internet access.

[rweijnen]

I always wondered why Evergreen didn't use a single Get function as it gets really messy when the number of applications grows so yes I think it's a great idea! Agree with @JimMoyle on the -Filter support, much better than using where-object. Besides language that you already mentioned, platform/bitness (32 or 64 bit) seems a very common thing for most apps and perhaps future will bring arm versions (or perhaps even non windows apps) as well. So perhaps a set of very common parameters/switches makes it easier than defaulting to Filter (which can still be used for very specific properties)

[DanGough]

Not many people needing 32-bit versions these days, but platform/bitness will certainly be useful going forwards for ARM builds!

[rweijnen]

Mostly true but of course there are exceptions such as apps with plugins (e.g. notepad++) as some plugins do not exist in 64-bit

[aaronparker]

@rweijnen Evergreen started very organically and there's not much consistency between how each function work given the nature of how to determine an application's current version and download. It is at a point where I'm now building more reusable code which is going to be needed for Get-EvergreenApp

[aaronparker]

First commit of Get-EvergreenApp

[Deyda]

Looks great. Thanks Aaron. Let me know when I can change my scripts :-)

[briantimp]

Looks promising!

[aaronparker]

I might look at releasing this on the 30th of March if I can update the documentation in time. I'll update the development branch this change in the next 24 hours.

[j81blog]

Will the "old" commands be still available for a while? Great work so far!

[aaronparker]

If you force install of the release before this version, yes, the commands will still be available.

[aaronparker]

I will release this updated version sometime next week. The code is ready to go, and documentation is updated so both will go live at the same time.

[DanGough]

This may be a temporary blip due to changes you are making but FYI https://stealthpuppy.com/Evergreen/index.html is returning a 404 right now.

[aaronparker]

New version has just gone live and this fixes the documentation issue while updating the content

[DanGough]

I've migrated to the new version and everything's running smoothly. Great job Aaron!