I want to write a script which cleans up all existing versions of Python on a machine, and a separate script to re-install both versions 2.7 and 3.5 in standardized locations. I'm currently trying to do this using the Package Management cmdlets in PowerShell 5.1.14393.187.
For the cleanup script, I started with PowerShell's package commands:
Get-Package "*python*" | Uninstall-Package
Which, when run from an admin console, seems to work nicely, but on further investigation leaves some packages remaining...
PS C:\WINDOWS\system32> Get-Package "*python*"
Name Version Source ProviderName
---- ------- ------ ------------
Python 3.5.1 (64-bit) 3.5.1150.0 Programs
Python 3.5.1 pip Bootstrap ... 3.5.1150.0 msi
Python 3.5.1 Tcl/Tk Support... 3.5.1150.0 msi
Python 2.7.11 2.7.11150 msi
Python 3.5.2 pip Bootstrap ... 3.5.2150.0 msi
Python 3.5.2 (32-bit) 3.5.2150.0 Programs
Why are these packages still present after Uninstall-Package? Is there a best-practice way to do this? Is there a best-practice way to script Python's re-installation so this won't happen again?
Update
I've had some success in cleaning up the majority of this by using the control panel GUI to first repair and then uninstall the Python 3 installations. I'm surprised there is no Repair-Package command to go with Get-Package.
Once the other parts of Python 3 were repaired, there was one MSI package called "Python Launcher", and the Python 2.7 MSI package remaining reported by Get-Package, but nothing in the GUI. At this point Uninstall-Package on the "Python Launcher" succeeded with a warning that a reboot was required. No such luck with msi:Python 2.7.11/2.7.11150.
Additional information:
I think Chocolatey v0.10.1 may have contributed to the current situation. At least some of the machines may have had python installed using chocolaty from the public repository. On the same machine above, I've also tried this:
PS C:\WINDOWS\system32> choco uninstall python
Chocolatey v0.10.1
Uninstalling the following packages:
python
python is not installed. Cannot uninstall a non-existent package.
Chocolatey uninstalled 0/1 packages. 1 packages failed.
See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).
Failures
- python - python is not installed. Cannot uninstall a non-existent package.
Did you know the proceeds of Pro (and some proceeds from other
licensed editions) go into bettering the community infrastructure?
Your support ensures an active community, it makes you look smarter,
plus it nets you some awesome features!
https://chocolatey.org/compare
PS C:\WINDOWS\system32> choco uninstall python3
Chocolatey v0.10.1
Uninstalling the following packages:
python3
python3 v3.5.1
Skipping auto uninstaller - No registry snapshot.
python3 has been successfully uninstalled.
Chocolatey uninstalled 1/1 packages. 0 packages failed.
See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).
PS C:\WINDOWS\system32> choco uninstall python2
Chocolatey v0.10.1
Uninstalling the following packages:
python2
python2 v2.7.11
Running auto uninstaller...
Skipping auto uninstaller - The application appears to have been uninstalled already by other means.
python2 has been successfully uninstalled.
Chocolatey uninstalled 1/1 packages. 0 packages failed.
See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).
PS C:\WINDOWS\system32> get-package "*python*"
Name Version Source ProviderName
---- ------- ------ ------------
Python 3.5.1 (64-bit) 3.5.1150.0 Programs
Python 3.5.1 pip Bootstrap ... 3.5.1150.0 msi
Python 3.5.1 Tcl/Tk Support... 3.5.1150.0 msi
Python 2.7.11 2.7.11150 msi
Python 3.5.2 pip Bootstrap ... 3.5.2150.0 msi
To answer this question I'm going to highlight a couple of points for you to consider.
Until official support has been announced, don't use the non-official PowerShell PackageManagement provider for Chocolatey. It is an unsupported preview subject to bugs and security flaws (it was also not created by the Chocolatey team). Instead use choco.exe, or another official provider.
AutoUninstaller is the resource in official Chocolatey clients that can remove natively installed software from packages that do not contain an uninstall script. It's important to note that you also need to install from those official clients. More information at https://chocolatey.org/docs/commands-uninstall
Why are these packages still present after uninstall-package?
It really depends on what you used to install the packages and whether Chocolatey was able to capture a snapshot for auto uninstaller.
Many packages do not require an uninstall script. Some do. When they are an MSI and are upgraded outside of Chocolatey (like Chrome does automatically), you either need Package Synchronizer or an uninstall script to uninstall the software.
Is there a best-practice way to do this?
If this is for organizational use, and you have a low tolerance for breakages, we recommend you build your own internal packages. Then you can completely control the process and have a repeatable, reliable process. This is how hundreds of organizations that use Chocolatey currently have enhanced their installation processes. They typically already have software installers already present on some internal file share and build packages around them to take advantage of better automation processes (versus old batch files they may have been using, or worse, manually installing from).
If you are curious on why you should build your own, see https://chocolatey.org/docs/community-packages-disclaimer (it attempts to highlight the issues with a public repository and it being subjected to distribution rights, something an internal repository is not subject to).
Is there a best-practice way to script python's re-installation so this won't happen again?
Use a configuration management tool like Puppet, Chef, Ansible, or DSC with the Chocolatey provider. https://chocolatey.org/docs/features-infrastructure-automation
This is how you create automation across all of your machines and take advantage of package management.
Related
Using Windows Server 2012 R2, on AWS.
When I install activeperl, chocolatey completes it successfully.
C:\Users\valentin.kragelj>choco install activeperl
Chocolatey v1.2.1
Installing the following packages:
activeperl
By installing, you accept licenses for the packages.
Progress: Downloading ActivePerl 5.28... 100%
ActivePerl v5.28 [Approved]
activeperl package files install completed. Performing other installation steps.
The package ActivePerl wants to run 'ChocolateyInstall.ps1'.
Note: If you don't run this script, the installation will fail.
Note: To confirm automatically next time, use '-y' or consider:
choco feature enable -n allowGlobalConfirmation
Do you want to run the script?([Y]es/[A]ll - yes to all/[N]o/[P]rint): y
Downloading ActivePerl 64 bit
from 'https://cli-msi.s3.amazonaws.com/ActivePerl-5.28.msi'
Progress: 100% - Completed download of C:\Users\valentin.kragelj\AppData\Local\T
emp\2\chocolatey\ActivePerl\5.28\ActivePerl-5.28.msi (5.52 MB).
Download of ActivePerl-5.28.msi (5.52 MB) completed.
Hashes match.
Installing ActivePerl...
ActivePerl has been installed.
activeperl may be able to be automatically uninstalled.
Environment Vars (like PATH) have changed. Close/reopen your shell to
see the changes (or in powershell/cmd.exe just type `refreshenv`).
The install of activeperl was successful.
Software installed as 'msi', install location is likely default.
Chocolatey installed 1/1 packages.
See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).
C:\Users\valentin.kragelj>
However when I check C:\ProgramData\chocolatey\bin there is no perl executable, and in C:\Perl64 there is only one file - perl.ico.
I'm firts time chocolatey user. What can I do about activeperl not being properly installed?
I have two different revision of PowerShell in different machines. The local one have the following one:
Major
Minor
Build
Revision
5
1
17763
1007
And the virtual machine has the following one:
Major
Minor
Build
Revision
5
1
17763
771
As you can see that it has the same: Major, Minor, and Build values except the Revision values. I am not sure if it is behind the failure of the command:
Register-PSRepository -Name $RepoKeyName -SourceLocation $RepoKeyValue
-PublishLocation $RepoKeyValue -InstallationPolicy Trusted -Verbose
The above snippet works fine on the local machine but not on the virtual machine and it fails in the virtual machine with the following error:
parameter 'SourceLocation' is an invalid Web Uri. Please ensure that it meets the Web Uri requirements.
And this is why I want to update the PowerShell in the virtual machine to the latest revision value. How to do it?
If you have Microsoft's winget app (Windows package manager), you can run the following command to update to the most recent version of PowerShell:
winget install Microsoft.PowerShell
If you're running Windows 11 or have updated App Installer in Windows 10.
Update PowerShell using Windows Package Manager (winget)
winget upgrade Microsoft.PowerShell
You also can install PowerShell by using below command via winget
winget install Microsoft.PowerShell
Learn more:
winget in Microsoft Docs
winget in GitHub repository
Run the following command from command prompt wait till gets downloaded, and it will prompt to installation wizard follow the instructions to install it.
Invoke-Expression "& { $(irm https://aka.ms/install-powershell.ps1) } -UseMSI"
You can never update Windows PowerShell installations on demand - except, in the past, if you upgraded to a new major version, but v5.1 is the last version that will ever be released, given that Windows PowerShell is in maintenance-only will see no new development, unlike its successor, the cross-platform PowerShell (Core) 7+ edition.[1]
Note:
While switching to the PowerShell (Core) edition[1] - where all future development effort will go - is advisable in general, doing so is not something to be done casually and requires a deliberate decision:
PowerShell (Core) is mostly, but not fully backward-compatible with Windows PowerShell, and certain cmdlets are unavailable, except via a compatibility feature that has its limitations both in terms of performance and type fidelity.
PowerShell (Core) is installed alongside Windows PowerShell and has different CLI (pwsh.exe rather than powershell.exe) and different SDKs (see this answer); also, targeting PowerShell (Core) via PowerShell remoting requires explicit configuration - see this answer.
Windows PowerShell-specific considerations:
Revisions of v5.1 are delivered as part of Windows updates.
However, you can selectively update the PowerShellGet module, in which the problem-causing Register-PSRepository command is defined:
While you normally would just run Update-Module PowerShellGet, a different approach is required the first time, when switching from the bundled PowerShellGet module to the latest version from the PowerShell Gallery:
Open an elevated session (Run as Administrator).
Execute the following (add -Verbose to get detailed information):
Install-Module PowerShellGet -Force
The -Force is to enable installation even though a module by that name is already installed; you may still see a prompt about downloading the NuGet package provider.
Note that the old PowerShellGet version will linger in a different location, but the new one will take precedence over it.
After this initial switch to the gallery-installed version, you'll be able to use
Update-Module PowerShellGet for future versions.
You can use the Get-Command cmdlet to discover a given command's module of origin; e.g.:
PS> (Get-Command Register-PSRepository).Module
ModuleType Version PreRelease Name ExportedCommands
---------- ------- ---------- ---- ----------------
Script 2.1.4 PowerShellGet {Find-Command, Find-DscResource, Find-Module, Find-RoleCapability…}
[1] PowerShell (Core) 7+ versions can be updated on demand - however, as of v7.2.x, PowerShell (Core) doesn't come with Windows and initially requires manual installation. However, you can now install and update it via the Microsoft Store application or, programmatically, using winget.exe (which comes with the App Installer Microsoft Store application, which recent versions of Windows ship with):
Initial installation:
winget install Microsoft.PowerShell
Later upgrade:
winget upgrade Microsoft.PowerShell
Note: Use Microsoft.PowerShell.Preview to install / upgrade the latest preview version instead.
Solution1:
Go to this link:
https://github.com/PowerShell/PowerShell/releases/
Find Assets and click on Assets word.
Download and install .msi link.
Solution2:
Go to this link for download Windows Package Manager:
https://github.com/microsoft/winget-cli/releases
Find Assets and click on Assets word.
Download : Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle
Execute the downloaded file and click on update.
Open your command prompt or powershell and execute this command on it:
winget install Microsoft.PowerShell
If you have Mircrosoft.PowerShell execute this command:
winget upgrade Microsoft.PowerShell
For figure out your powershell version: execute host command in your powershell.
I have installed boost-msvc14 1.59.0 but whenever I try installing osquery it says that it didn't find boost-msvc14 1.59.0 .
My boost directory is in C:/local. powershell is very slow in terms of downloading that's why I don't want to use powershell to install it. How can I fix this problem?
Old question. In recent osquery builds, you can use the make-win64-dev-env.bat, which uses Chocolatey packages. They get placed in \ProgramData\chocolatey. You can run choco list -l to list your installed packages.
I just installed Canopy Express 1.4.1 (32-bit) for Windows. Among the packages that are supposed to be there (see https://www.enthought.com/products/canopy/package-index/ ) are pandas and statsmodels. But after installing, neither is listed in Package Manager, either as being installed or available.
The lack of pandas is not a problem, as pip easily installs it. (Enthought notes that packages installed that way will not be listed in Package Manager, but are fully available in the Canopy User Environment. Indeed, it imports.
statsmodels is not so easy. pip only gets source, and there is no Windows installer provided by the statsmodels folks. There is a nightly Windows binary, but not (if I'm reading correctly) for the stable build. The suggested solution by statsmodels is to compile it, using MinGW, which I do not currently have installed.
With enough trouble, I imagine I could compile and install, but is there a way to save all that trouble and get the packages within Canopy, as Enthought says it should be?
Seems like your Package Manager is misbehaving or you are looking in the wrong place (look in Free Packages not Community Packages).
Pandas is indeed in the Express installer, so always installed. At Canopy's python prompt, type:
import pandas
Though sounds like you've already overwritten it with pip, not really a problem but not the cleanest path (mixing 2 different installation methods for the same package).
Statsmodels is listed in package manager (Free package). It is available to free users but is not yet in the Express installer.
If you still don't see these in the pkg mgr, please quit Canopy, ensure that all Canopy processes have terminated (easiest way... log out of Windows, then back in), and restart Canopy.
I was trying to use Nuget as a software deployment system (repository, versioning and delivery) - idea from Octopus. Previously I was packaging ASP.NET sites into a self-extracting RAR archives with a .CMD startup scripts embeded. Now I'm trying to use Nuget creating puckages during automated build. The issue is that the package installation scripts (tools\Install.ps1 or tools\Init.ps1) do not execute if the package is being installed using command line:
nuget.exe install <package_id> -OutputDirectory <install_folder> -source <local_repo>
Same scripts are able to execute when package installed from Visual Studio Package Manager or Console.
I do not see why this shouldn't be possible given omnipresence of PowerShell.
Am I missing something or this is behaviour by design? Will appreciate you help.
Yes, we did consider MSDeploy but we already have install scripts that do the same thing and give more control and we need some strong package management and repository for build artifacts (something that Java folks do with Maven).
As of today, the powershell scripts are not invoked from doing installations from command line.
One reason for this is that, in general, most of the install/init actions are tied to dte and the visual studio project and doesn't add much value to be able to run it from outside VS.
We have a backlog item for enabling support for exe based scripts too in addition to powershell.