https://oneget.codeplex.com/workitem/10

An example is VisualStudio2013Ultimate. I was running this via DSC using the xOneGet resource. The package succeeds but the package does not fall into the /lib directory causing repeat runs to redownload and reinstall. The package includes a dependency on DotNet4.5.1 which DOES land in the /lib directory.

2 votes
Reported by:
Apr 8 at 9:15 AM Smica (contact)

Almost powershell's bundled cmdlets don't rely on powershell engine.
So, if powershell team separates bundled cmdlets from powershell environment, we can get following benefits.
OneGet can implement it, I think.

more rapidly updates

Currently bundled cmdlets are in powershell, so we must wait for next powershell (== next OS) in order to update cmdlets.
If we can get updated cmdlets from OneGet, we don't have to wait.
This benefit is specially remarkable with security updates.

more flexible backport
Even if bundled cmdlets don't rely on new powershell engine, if new powershell doesn't support Win7, we can't use them on Win7.
If we can get updated cmdlets from OneGet, we can use them without new powershell.
(and, new powershell / PS team don't have to support old OS ;-)

Naturally, some cmdlets would rely on powerhsell engine.
So powershell team would need to pick out them.

comments
bherila wrote Apr 8 at 2:54 PM [x]

We plan to release OneGet builds independently of PowerShell, even though PowerShell includes OneGet by default.

Hello,
I just installed the Windows Management Framework 5.0 Preview September to test OneGet with Chocolatey. But this provider seems to be removed from the September release.

How can I add this provider?

thx

I see that there's no "Update-Package" command, instead there's an -InstallUpdate switch.

I think the -InstallUpdate switch ought to be just -Update (possibly use an alias for InstallUpdate to maintain compatibility). When I was trying to use the command, I tried -U{Tab} looking for an update parameter, but even looking at the syntax blocks I didn't notice the -InstallUpdate parameter until I used search to highlight it 🎱

Additionally I ran these two commands, and then edited the PSCX module manifest to downgrade it's version number, and then ran the second command again.

Install-Package PSCX -Provider PSModule
Install-Package PSCX -Provider PSModule -InstallUpdate -Verbose

I was dismayed to find that the version number of the existing version is just never displayed anywhere in the verbose output. That would be nice to fix too.

P.S.: Is the behavior of InstallUpdate up to the provider? I assume so.

Some Chocolatey packages (e.g. nodejs) depend on the fact that when Chocolatey is in stalled, it adds C:\Chocolatey\bin to the PATH environment variable to integrate commands. For example, nodejs drops a file named 'node.bat' into that directory expecting users can then use the 'node' command. Trying to use the "node" command fails is nodejs is installed by OneGet on a machine that never had Chocolatey installed.

https://oneget.codeplex.com/workitem/7
Provide a command to download (but not install) a package via OneGet and another to upload a package to a repository. This is useful to be able to copy a package from an untrusted public repository, validate it doesn't do anything harmful, and then copy it to a trusted local repository.

comments

bherila wrote Apr 9 at 9:14 PM [x]
◾Download (but not install) is in our roadmap
◾Upload is something we are not committing to right now, but we are closely monitoring the community feedback and may consider adding in a future release.

If you have things you'd like me to cover, post it here; if we don't cover it this week, we'll add it to next week's meeting.

Meeting is done via Lync (-you can join from your browser- ) connection details will be at http://oneget.org/weekly/meeting.html

Usual Topics

News
Happy Workanviersary To Me!
Taking off next week.

What's new

November WMF 5 release

Design Discussions

*Discover the dirty, dark secret about OneGet *
It's all about testing this week

• Using Pester for Automated PowerShell testing
• Using ProGet as a local test repository
• thoughts about framework for testing specific providers (validate they behave within appropriate parameters)
• other ideas?

To help increase trust with inherently untrusted providers, after Install-Package downloads a package locally but before executing/installing the package, a suitable cryptographic hash algorithm should be used to calculate a checksum/digest of the package.

The user can optionally specify the expected checksum as an additional Install-Package parameter and only if the downloaded package's checksum matches the specified checksum would the installation be allow to continue. eg:

Install-Package -Package dotpeek -Checksum da39a3ee5e6b4b0d3255bfef95601890afd80709

Inevitably it would be useful to introduce a cmdlet that can calculate and display the checksum of a package so that it can be noted and used in future calls to Install-Package.

For providers like Chocolatey, where the package itself is not always self contained and will often download additional payloads from other sources, calculating an overall checksum may be complex. However I'm sure a solution can be found with some investigation and collaboration.

I create the dynamic option in Get-DynamicOptions
New-DynamicOption -Category $category -Name "MyUser" -ExpectedType StringArray -isRequired $true

I guessed to get the value this way, in Find-Package
$MyUser=$request.YieldDynamicOption("MyUser", "StringArray", $true)

Get this in the console.
SHOULD NOT GET HERE [YieldSoftwareIdentity] ================================================

But it shouldn't because according to this 7z archives are supported by chocolatey. Also, compression rates for 7z archives are so much better than zip files that this makes quite a difference for larger packages.

https://oneget.codeplex.com/workitem/14

When using Add-PackageSource, there is no verification of whether the source actually exists. It just adds the source with no questions asked and you won't know until you attempt to find/install a package that the path is not valid.
Add-PackageSource -Name Fail -Location http://this.willnotwork.com/keeptrying -Provider Chocolatey
Even though this is obviously wrong, it is still added and appears in the list of sources when using Get-Packagesource.

Some sort of checking, be it using Invoke-WebRequest (if url; otherwise Test-Path for folder) or some other approach to verify the validity of the location would help to ensure that the proper package sources are being added to the list of available sources.

file attachments

◾ Example.PNG [x]

comments

christoph_hausner wrote Apr 7 at 3:43 AM [x]

What if you currently don't have internet access but still want to add a package source?

boeprox wrote Apr 7 at 4:19 AM [x]

I would recommend having an additional parameter such as -NoVerify or -DoNotCheck to skip the checking of the source.

fearthecowboy wrote Apr 7 at 12:28 PM [x]

We've talking about handling repository verification during add-packagesource

It's always going to be up to the package provider to validate a location, although we'll expose this thru the plugin-model API.

I'm torn between making it verify it by default, or making the verification check a switch.

Add-PackageSource -Name foo -Location http://foo -Provider Chocolatey -NoVerify

vs

Add-PackageSource -Name foo -Location http://foo -Provider Chocolatey -Verify

I'm going to consult the PowerShell core team to see which way they'd like it, and get back to you.

bherila wrote Apr 7 at 2:24 PM [x]

I would recommend having an additional parameter such as -NoVerify or -DoNotCheck to skip the checking of the source.

Can't we just use -Force for that? I'm in favor of verification by default.

boeprox wrote Apr 7 at 8:09 PM [x]

Can't we just use -Force for that? I'm in favor of verification by default.
I would vote for a -Force parameter as long as there is some sort of confirmation prompt if verification of the source fails during the addition of the package source and -Force is not specified. I am also in favor of it verifying by default and being ignored if the -Force parameter is used.

Just an example of what I am talking about:
Function Add-PackageSource {
[cmdletbinding()]
Param (
$Name,
$Location,
$Provider,
[switch]$Trusted,
[switch]$Force
)
If ($PSCmdlet.ShouldProcess("Add-PackageSource","$Location")) {
$Verified = (Get-Random -InputObject ($False,$True)) #
If (-Not $Verified) {
If ($Force -OR $PSCmdlet.ShouldContinue("Continue adding $($Location)?","Unable to Verify!")) {
#Continue adding the source
}
}
}
}
More info on cmdlets using Confirmation and -Force here and here.

https://oneget.codeplex.com/workitem/5

VERBOSE: NuGet:Installing 'IsePester 1.0.2'.
VERBOSE: NuGet:Successfully installed 'IsePester 1.0.2'.
install-package : FAILURE:IsePester, You cannot call a method on a null-valued expression.
At line:1 char:1

• install-package isepester -Verbose

• - CategoryInfo          : OperationStopped: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Package],  
    Exception
  - FullyQualifiedErrorId : errorid,Microsoft.PowerShell.OneGet.CmdLets.InstallPackage
  
  

VERBOSE: PostProcessPackageInstall or YieldPackage threw exception:Exception/Failed executing chocolatey script.

at Microsoft.OneGet.Plugin.Chocolatey.ChocolateyScript.InvokeChocolateyScript(String command, String[] arguments)

at Microsoft.OneGet.Plugin.Chocolatey.ChocolateyState.InvokeChocolateyScript(String packageFolder, String
packageName, String path)

at Microsoft.OneGet.Plugin.Chocolatey.ChocolateyState.PostProcessPackageInstall(String pkgName, String pkgVersion)

at Microsoft.OneGet.Plugin.Chocolatey.ChocolateyState.InstallSingleChocolateyPackage(PackageReference
packageReference)

OneGet is a package management aggregator.

In order to fill out the goal of comprehensive package management in Windows, we need to come up with a list of package providers (types of existing package managers) that we'd like to see plugins created for OneGet for.

The list starts off fairly easy, but we need to get as much of these captured as possible.

Package Managers

# using the format:
[$NAME]($WEB) | unassigned | (none) | $DESCRIPTION.

OneGet also supports pluggable archive formats:

Archive Formats

As well as pluggable downloader schemes:

Downloaders

Remember:

Package Providers can leverage other package providers in their implementation (ie, the PSModule provider uses the NuGet Provider and the Chocolatey uses the MSI, MSU and VSIX Providers

Please feel free to add any package manager to this list (just specify the details in this thread, I'll edit this post, and then delete your message)

I did not dig deeper. Scriptcs has a dependency in the nuget commandline, which it does install, but it does not install the Roslyn dependencies. I suspect they are specified in the install.ps1

Should probably note this somewhere in Readme.md.

PowerShell Tools for Visual Studio
http://visualstudiogallery.msdn.microsoft.com/c9eb3ba8-0c59-4944-9a62-6eee37294597

Would be nice to have an option to update installed packaged when a new version becomes available.

Subject.

https://oneget.codeplex.com/workitem/11

Example: mssqlserver2012express. This was installed via DSC using the xOneGet resource. The package succeeded. By "succeeded" I mean the sql install logs reported success wit an exit code of 0 and the product was functioning. However, the following was reported:

InstallFailure:Package 'MsSqlServer2012Express' not installed

• CategoryInfo : OperationStopped: (Microsoft.Power....InstallPac
  kage:) [], CimException
• FullyQualifiedErrorId : errorid,Microsoft.PowerShell.OneGet.CmdLets.Inst
  allPackage
• PSComputerName : win81

The PowerShell provider MSFT_xOneGet threw one or more non-terminating errors
while running the Set-TargetResource functionality. These errors are logged to
the ETW channel called Microsoft-Windows-DSC/Operational. Refer to this
channel for more details.

• CategoryInfo : InvalidOperation: (:) [], CimException
• FullyQualifiedErrorId : NonTerminatingErrorFromProvider
• PSComputerName : win81

When using Add-PackageSource, there is no verification of whether the source actually exists. It just adds the source with no questions asked and you won't know until you attempt to find/install a package that the path is not valid.

Add-PackageSource -Name Fail -Location 'http://this.willnotwork.com/keeptrying' `
-Provider Chocolatey

Even though this is obviously wrong, it is still added and appears in the list of sources when using Get-Packagesource.

Some sort of checking for either a web location or folder location would help to ensure that the proper package sources are being added to the list of available sources.

Suggest having a confirmation prompt if it cannot successfully validate the location asking to continue adding the source or to exit. Adding a -Force parameter would allow this to suppress the prompt and continue adding the package source.

Please tell me what am I doing wrong.

Everything seems to be working, using the -Force switch I can install any package but just the package, the application itself will not be installed, its installer .exe or .msi not downloaded. Even the packages won't install without -Force.

Windows 10 Technical Preview Build 9860, elevated PS ISE, Executionpolicy RemoteSigned. Example output, trying to install Opera browser:

PS C:\Windows\system32> find-package Opera | Install-Package -Force -Verbose
VERBOSE: In PSModule Provider - 'Get-DynamicOptions'.
VERBOSE: In PSModule Provider - 'Get-DynamicOptions'.
VERBOSE: In PSModule Provider - 'Get-DynamicOptions'.
VERBOSE: In PSModule Provider - 'Get-DynamicOptions'.
VERBOSE: Calling 'NuGet::GetDynamicOptions' 'Provider'
VERBOSE: Calling 'NuGet::GetDynamicOptions' 'Source'
VERBOSE: Calling 'NuGet::GetDynamicOptions' 'Package'
VERBOSE: Calling 'NuGet::GetDynamicOptions' 'Install'
VERBOSE: In PSModule Provider - 'Install-Package'.
VERBOSE: The FastPackageReference is 'NuGet|Opera|25.0.1614.63|http://chocolatey.org/api/v2/'.
VERBOSE: OPTION: Force => True
VERBOSE: OPTION: Verbose => True
VERBOSE: OPTION: Source => http://chocolatey.org/api/v2/
VERBOSE: OPTION: InputObject => Microsoft.OneGet.Packaging.SoftwareIdentity[]
VERBOSE: The specified Location is 'NuGet' and OneGetProvider is 'NuGet'.
VERBOSE: Downloading module 'Opera' with version '25.0.1614.63' from the repository 'http://chocolatey.org/api/v2/'.
VERBOSE: Calling 'NuGet::InstallPackage'
VERBOSE: Calling 'CommonServiceProvider::GetKnownFolder'
VERBOSE: NuGet: GET http://chocolatey.org/api/v2/Packages(Id='Opera',Version='25.0.1614.63')
VERBOSE: NuGet: GET http://chocolatey.org/api/v2/package/Opera/25.0.1614.63
VERBOSE: NuGet: Installing 'Opera 25.0.1614.63'.
VERBOSE: NuGet: Successfully installed 'Opera 25.0.1614.63'.
VERBOSE: Module 'Opera' was installed successfully.

Name Version Status Source Summary

Opera 25.0.1614.63 Installed http://choc... The Opera web browser makes the Web fast and fun, giving you a better web brows...

I have used Chocolatey some time now, I have no issues in installing the same apps with "choco install XXXX".

I assume this is a user error but I can't figure out what am I doing wrong.

Kari

This is a NuGet provider bug. Repro steps are:

Save-Package -Name Adept.nugetrunner -provider nuget -destination c:\temp
-->
Install-Package -Name Adept.nugetrunner -provider nuget -destination c:\temp

Install-Package simply executes and does nothing. If you then delete the package you saved in c:\temp and run install, it will actually install it into the directory, so i'm guessing it is having issues installing when something is actually saved there.

https://oneget.codeplex.com/workitem/6
The ChocolateyInstall environment variable is not being set by OneGet and some packages are failing to install. The Chocolatey packaging reference (https://github.com/chocolatey/chocolatey/wiki/CreatePackages) mentions the variable as a valid path to use in packaging, so OneGet needs to be setting it appropriately.

A sample package that fails to install unless the variable is set is ilspy 2.1.0.1000. The install is successful if I set $env:chocolateyinstall = "c:\programdata" or "c:\users\cduck\appdata\local"

https://oneget.codeplex.com/workitem/8
Example: DotNet3.5. This package is just a call to cinst netfx3 -source WindowsFeature.

The package cant use nuspec dependencies due t othe special source and if working on a client SKU, the WindowsFeature resource is not an option.

There are many packages that use cinst to create a "meta" package and provides more control over execution order and custom scripts between packages than using the nuspec dependencies.

The installation script seems to try to convert localized time strings to System.DateTime object without success.

Install-Package : Cannot convert value "2014/9/29 下午 11:29:53 +08:00" to type "System.DateTime". Error:
 "The string was not recognized as a valid DateTime. There is an unknown word starting at index 10."
At line:1 char:1
+ Install-Package -name git -Source chocolatey -verbose
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (Microsoft.Power....InstallPackage:InstallPackage) [Ins
   tall-Package], Exception
    + FullyQualifiedErrorId : InvalidCastParseTargetInvocationWithFormatProvider,New-PSGetItemInfo,Mic
   rosoft.PowerShell.OneGet.CmdLets.InstallPackage

A global to just say yes I know it's unsafe install it anyway would be great. Right now I primarily use choclatey with boxstarter. You can launch Install-Package in a boxstarter script, but I really don't want to have to confirm a dozen or more packages.

Error

VERBOSE: NuGet:Installing 'IsePester 1.0.2'.
VERBOSE: NuGet:Successfully installed 'IsePester 1.0.2'.
install-package : FAILURE:IsePester, You cannot call a method on a null-valued expression.
At line:1 char:1
+ install-package isepester -Verbose
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Package],  
   Exception
    + FullyQualifiedErrorId : errorid,Microsoft.PowerShell.OneGet.CmdLets.InstallPackage

VERBOSE: PostProcessPackageInstall or YieldPackage threw exception:Exception/Failed executing chocolatey script. 

   at Microsoft.OneGet.Plugin.Chocolatey.ChocolateyScript.InvokeChocolateyScript(String command, String[] arguments)

   at Microsoft.OneGet.Plugin.Chocolatey.ChocolateyState.InvokeChocolateyScript(String packageFolder, String 
packageName, String path)

   at Microsoft.OneGet.Plugin.Chocolatey.ChocolateyState.PostProcessPackageInstall(String pkgName, String pkgVersion)

   at Microsoft.OneGet.Plugin.Chocolatey.ChocolateyState.InstallSingleChocolateyPackage(PackageReference 
packageReference)

Transcript

**********************
Windows PowerShell transcript start
Start time: 20140405141928
Username  : MAINBOX\Douglas 
Machine   : MAINBOX (Microsoft Windows NT 6.2.9200.0) 
**********************
Transcript started, output file is .\oneget.txt
PS C:\> install-package isepester -Verbose

Installing Package 'IsePester' from untrusted source
WARNING: This package source is not marked as safe. Are you sure you want to install software from 'chocolatey'
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"): y
VERBOSE: CreateFolder Success:C:\Chocolatey\lib
VERBOSE: Performing the operation "Install Package" on target "pester".
VERBOSE: NuGet:Installing 'Pester 2.0.4'.
VERBOSE: NuGet:Successfully installed 'Pester 2.0.4'.

Name                             Version          Status           Source         Summary                              
----                             -------          ------           ------         -------                              
pester                           2.0.4            Installed        chocolatey     A BDD style testing tool for Power...
VERBOSE: Performing the operation "Install Package" on target "IsePester".
VERBOSE: NuGet:Attempting to resolve dependency 'pester'.
VERBOSE: NuGet:Installing 'IsePester 1.0.2'.
VERBOSE: NuGet:Successfully installed 'IsePester 1.0.2'.
install-package : FAILURE:IsePester, You cannot call a method on a null-valued expression.
At line:1 char:1
+ install-package isepester -Verbose
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Package],  
   Exception
    + FullyQualifiedErrorId : errorid,Microsoft.PowerShell.OneGet.CmdLets.InstallPackage

VERBOSE: PostProcessPackageInstall or YieldPackage threw exception:Exception/Failed executing chocolatey script. 

   at Microsoft.OneGet.Plugin.Chocolatey.ChocolateyScript.InvokeChocolateyScript(String command, String[] arguments)

   at Microsoft.OneGet.Plugin.Chocolatey.ChocolateyState.InvokeChocolateyScript(String packageFolder, String 
packageName, String path)

   at Microsoft.OneGet.Plugin.Chocolatey.ChocolateyState.PostProcessPackageInstall(String pkgName, String pkgVersion)

   at Microsoft.OneGet.Plugin.Chocolatey.ChocolateyState.InstallSingleChocolateyPackage(PackageReference 
packageReference)
VERBOSE: Removing Package:C:\Chocolatey\lib\IsePester.1.0.2
VERBOSE: Current Process is:Elevated


PS C:\> Stop-Transcript
**********************
Windows PowerShell transcript end
End time: 20140405141946
**********************

Steps performed:

• Created a private myget feed which hosts private chocolatey packages
• Add-PackageSource -Name initech -Location https://www.myget.org/F/initech-chocolatey -Trust -Provider Chocolatey
• Install-Package -Source initech

Exception:
No Package Found

Expected:
prompt for credentials (basic auth: username/pwd)

Alternatively:
since chocolatey provider is using nuget under the hood, storing nuget credentials in nuget.config could be taken into account (tried, doesn't work)

Currently, the only way to adjust an already existing PackageSource is to go into the chocolatey.config file and edit the information or use Add-PackageSource with the same values (except for the value that needs changed). Having a Set-PackageSource cmdlet would fill in this issue.

https://oneget.codeplex.com/workitem/3
Currently, the only way to adjust an already existing PackageSource is to go into the chocolatey.config file and edit the information or use Add-PackageSource with the same values (except for the value that needs changed). Having a Set-PackageSource cmdlet would fill in this issue.

Perhaps these exist but I could not find them and they were not where they would be when using the Powershell based chocolatey client. At a minimum these should include the verbose output but more detail would be gret including output from Nuget.exe, exit codes after the chocolatey run and any output sent to std out that OneGet might not be sending to the console.

https://oneget.codeplex.com/workitem/12

comments
fearthecowboy wrote Apr 7 at 12:30 PM [x]

You are correct, the current prototype doesn't do any logging at all.

I have some work in this area coming up soon, I'll get back to you on that.

You must separate the parameters of Install-Package into their parameter sets. There are a bunch of combinations that aren't valid, but are indicated as valid according to the parameter set syntax help. For instance, this error should never happen:

Install-Package : The parameters MinimumVersion and RequiredVersion cannot be used in the same command. Specify only one of these parameters in your command.

Ideally, all of the commands ought to have a "simple" parameter set that people can grok easily, and then more complicated ones. As it is, they just go straight to complicated -- even when all of the parameters are marked optional ;-)

Also, the Name parameter has to be mandatory. It's terrifying to think of accidentally installing all the packages...

I think my goal would be to separate the ones that cannot go together, and then, to remove all but the most basic parameters from the default parameter set, so that there would be a simple block like this:

    Install-Package [-Name] <string[]> [-InstallUpgrade] [-WhatIf] [-Confirm] [<CommonParameters>]

Maybe even an intermediate one like:

    Install-Package [-Name] <string[]> -ProviderName <string[]> [-Location <string>] 
                   [-Source <string[]>] [-Credential <pscredential>] [-InstallUpgrade] 

Of course, I'm mostly guessing here, because there's no help yet, and:

1. Obviously MinVersion, MaxVersion, RequiredVersion, and ExcludeVersion need to be broken up into parameter sets that make sense (and should not appear on the default parameter set).
2. I can't tell what Location vs Destination mean, and how they relate to PublishLocation
3. I don't know why there's a ProviderName and also a OneGetProvider
4. I can't imagine why ForceBootstrap should not be relegated to it's own separate command, or at least a separate parameter set.
5. I don't understand what ContinueOnFailure is doing here. Shouldn't you just use the common ErrorAction parameter and the ErrorActionPreference value?
6. I believe Scope should be an Enum, not a string, but I'm okay with leaving it. However ...
7. PackageSaveMode should be a flag enum. And if you don't want to write the enum, it should at least look like one, and the options should be "nuspec", "nupkg", and "nuspec, nupkg" (with a comma, not a semicolon).... or it should accept a string array, and have just "nuspec" and "nupkg" in the validate set (since you could pass both).
8. I have no idea what Tag or Contains are doing on the Install command -- they sound like something from Find (and I'd much rather have them only there, if they are for searching). Additionally, even if you were to leave them, I'm assuming they can't really be used with the SoftwareIdentity parameter set...

P.S. I overcame my terror and ran Install-Package without any parameters, and it seems like it basically tried to install every package there was, but then decided that since it couldn't pick just one, it wouldn't install anything. Obviously the name parameter has to be mandatory.

Install-Package arduinoide is one example of a package that will cause this error, processing2 is another. This occurs with or without the -Force option.

We need a better way of implemeting -WhatIf so that the package provider isn't just inspecting the flag (which if they didn't do, it'd work wrong).

Investigate.

https://oneget.codeplex.com/workitem/2
Currently, only Chocolatey is supported as a provider in Add-PackageSource, but there is no mention of this when the command fails due to an 'unknown provider'. By using [ValidateSet('Chocolatey')] with the Provider parameter an error would still be thrown, but it would then list out what the possible values are allowed. This would help others to know what are the possible values. This will also help with future additions of available providers

I'm cleaning up some of the arguments and whatnot and I'm trying to decide how far to go in some places.

In order to ensure that I'm not replicating code that could be consistent, I've refactored the cmdlets into essentially 5 base classes in a hierarchy:

AsyncCmdlet
   └─── abstract CmdletBase  
      │     
      ├───Get-PackageProvider
      │     
      └─── abstract CmdletWithProvider
          │    // user may specify a provider -- no provider means 'all' 
          │    // can come from the cmdline, or pipeline 
          │    
          ├───Get-PackageSource
          │
          ├───Register-PackageSource
          │
          ├───abstract CmdletWithSource
          │  │  // [ADDS] user may specify one or more sources  -- no provider means 'all' 
          │  │  // may come from cmdline or pipeline.
          │  │
          │  └───Unregister-PackageSource
          │
          └─── abstract CmdletWithSearch
             │  // [ADDS] user may specify name, maxver, minver, reqver
             │  // name may come from pipeline.
             │
             ├───Get-Package
             │
             ├───Uninstall-Package
             │
             └─── abstract CmdletWithSearchAndSource
                │  // [ADDS] user may specify one or more sources  -- no source means 'all' 
                │  // may come from cmdline or pipeline.
                │
                ├───Find-Package
                │
                └───Install-Package

When selecting who to talk to, the cmdlets narrow by:

• explicitly by specified provider
• explicitly by specified sources
• implicitly by dynamic options used (using a dynamic option implies that you want to use just providers that have that dynamic option).

This thinking has posed a few questions, that I currently don't do:

1. Should the user be able to specify more than one Provider at a time? Is there a use for that?
2. Should the pipeline-parameters support taking more than one (source, provider) at a time?

Scratchpad:

# case for why you might want the cmdlets to take a set of providers:
> get-packageprovider | where <something> | find-package zlib 

# But does that actually make sense? isnt' it more appropriate to do that with sources?
> get-packageprovider | where<something>  | get-package-source | find-package zlib 
    # gets the package providers, filters on something, then gets the sources 
    # from those and then calls find-package.
    # although, the first example does that too, because passing a provider implicitly filters
    # sources to that provider.

# is this really very useful?
> find-package -provider NuGet, Chocolatey -name foobar

# thinking...
> find-package -source chocolatey.org,myprivaterepo,http://some/other/repo -name goober

https://oneget.codeplex.com/workitem/9
The Install-ChocolateyZipPackage helper is extracting all files into the destination folder and not preserving the zip file's folder structure.

msmtp.portable is an example package that should extract with subfolders but is only extracting to a flat folder.

Reported by: Apr 11 at 9:58 AM Jaykul (contact)
Updated by: alanrenouf

Currently, there's no Update-Package, so there's no way to support upgrades.

In fact, if you call Install-Package on a package you already have installed, and there's a new version, it just does an install as a new package (in Chocolatey, it ends up unpacked side-by-side in the lib folder) and worse, the package manager forgets that the old version exists -- thus, when you call uninstall-package, it doesn't clean up old versions, only the most recent.

Reported by:
Apr 11 at 10:15 AM Jaykul (contact)
Updated by: Apr 11 at 1:08 PM alanrenouf

After calling Install-Package with a name and required version, I end up with multiple side-by-side installs, but Get-Package and Uninstall-Package don't know about versions and do different things. For example:

[326]: Install-Package Astley -Force

Name Version Status Source Summary

Astley 3.0 Installed chocolatey

[327]: Install-Package Astley -RequiredVersion 1.0 -Force

Name Version Status Source Summary

Astley 1.0 Installed chocolatey

[328]: Install-Package Astley -RequiredVersion 2.0 -Force

Name Version Status Source Summary

Astley 2.0 Installed chocolatey

[329]: Install-Package Astley -RequiredVersion 2.1 -Force

Name Version Status Source Summary

Astley 2.1 Installed chocolatey

[331]: Install-Package Astley -RequiredVersion 2.2 -Force

Name Version Status Source Summary

Astley 2.2 Installed chocolatey

Name Version Status Source Summary

Astley 1.0 Installed Local File
Astley 2.0 Installed Local File
Astley 2.1 Installed Local File
Astley 2.2 Installed Local File
Astley 3.0 Installed Local File
autoload 4.1 Installed Local File
PoshCode 4.0.1.11 Installed Local File
reflection 4.5 Installed Local File
wasp 2.5.0.0 Installed Local File
zoomit 4.50 Installed Local File ZoomIt is a scr

[333]: Get-Package Astley

Name Version Status Source Summary

Astley 1.0 Installed Local File

Get-Package ought, by default to return all versions, not just the oldest. Get-Package and Uninstall-Package really also ought to have a way to return a specific one, this is ridiculous:
[334]: Get-Package Astley | Uninstall-Package

Name Version Status Source Summary

Astley 1.0 Not Installed

[335]: Get-Package Astley

Name Version Status Source Summary

Astley 2.0 Installed Local File

[335]: Get-Package Astley

Name Version Status Source Summary

Astley 2.0 Installed Local File

[336]: Uninstall-Package Astley

Name Version Status Source Summary

Astley 2.0 Not Installed

[337]: Get-Package Astley

Name Version Status Source Summary

Astley 2.1 Installed Local File

https://oneget.codeplex.com/workitem/1

From an interactive remote session calling Install-Package or Uninstall-Package just returns a prompt back. No warning or error to indicate that the package was not successfully installed or uninstalled on the remote endpoint. In addition specifying -Verbose or -Whatif have no effect.

Image

Would be quite cool to have the ability to install and uninstall packages remotely via Remoting.

boeprox wrote Apr 8 at 6:53 PM [x]
Someone else seemed to have success with using the -Force parameter to install a package and blogged about it:

http://mikefrobbins.com/2014/04/08/using-the-powershell-version-5-preview-oneget-module-with-powershell-remoting/

https://oneget.codeplex.com/workitem/4
Remove-PackageSource does not currently support pipeline input.

I downloaded the latest OneGet.

I added MyTestPackageProvider.psm1 (also tried MyTest.psm1) to the $PSHOME\Modules\oneget. Did an ipmo oneget -force, then tried Get-PackageProvider but don't see this provider there.

Reported by: Apr 11 at 10:01 AM Jaykul (contact)
Updated by: Apr 11 at 1:08 PM alanrenouf

Currently you can install multiple versions of packages side-by-side (depending on support from the underlying package manager and package). However, Uninstall-Package will only uninstall the latest version, and once that's gone, forgets the older versions are still installed.

Test-TargetResource uses

$package = Get-Package -Name $PackageName -Verbose

which throws if the package is not found locally.

You can add -ErrorAction Ignore to get around it but probably not the Right Thing To Do.

This event indicates that a non-terminating error was thrown when DSCEngine was executing Test-TargetResource on MSFT_xOneGet DSC resource. FullyQualifiedErrorId is errorid,Microsoft.PowerShell.OneGet.CmdLets.GetPackage. ErrorMessage is No installed packages found for Name 'zoomit'.:.

Once you fix this....It still doesn't work. Still get a Package Installation Failed no matter what package.

This event indicates that a non-terminating error was thrown when DSCEngine was executing Set-TargetResource on MSFT_xOneGet DSC resource. FullyQualifiedErrorId is errorid,Microsoft.PowerShell.OneGet.CmdLets.InstallPackage. ErrorMessage is PackageInstallation Failed:TcpView.

https://oneget.codeplex.com/workitem/13

please also add support for Npackd (https://code.google.com/p/windows-package-manager/)

Thank You

comments

fearthecowboy wrote Apr 7 at 12:29 PM [x]

We'll have details on the plugin model and a sample/template that you can play with in a few weeks. Once that's out, anyone will be able to start building a package handler.

G

tim_lebedkov wrote Apr 8 at 3:18 PM [x]

I will have this in mind.

I just saw this in the "General Q and A":

What package managers are supported?
Today, just Chocolatey. We will certainly be working on more in the future.

Importing the dll from http://oneget.org/provider-cs.zip and manually setting up a process to link it into one binary feels dirty.

I would like to see Microsoft push new releases of WMF to their OneGet NuGet repo. I would like to either install-package, or update-package to be able to update WMF.

Garett is aware of this request via twitter.

Having the ability to run oneget install-package would make me very happy. Also being able to run oneget /? to get limited help/documentation would also be fantastic.

I'm not very familiar with PowerShell, and work mostly with *nix systems and the CMD.exe terminal. Behavior mirroring what i'm used to with other package managers would make integrating OneGet into existing workflows and mental models much easier.

IMO this would be a great feature for down the line when OneGet is exposed to the traditional CMD prompt.

In an attempt to make sure that I don't forget topics; I'm starting to publish a running list of things that I'd like to cover at this week's OneGet meeting.

If you have things you'd like me to cover, post it here; if we don't cover it this week, we'll add it to next week's meeting.

Meeting is done via Lync (-you can join from your browser- ) connection details will be at http://oneget.org/weekly/meeting.html

Usual Topics

• What's new
• Demo

Events this last week

• What happened at the MVP Summit
• MVP Summit Presentation (it's a very fun watch)

Design Discussions

• Find-Package - Expensive vs Cheap data (and the use of GetPackageDetails)
• Ideas on Unique package identification (and products, etc)
• Ideas for Canonical Package Identity
• Notions of 'Upgrade' vs 'Update'
• Swidtags (Discovery and Inventory)
• Security: provider/source/package trustworthiness
• Security: privilege escalation attacks/mitigations
• Security: provider bootstrapping attacks/mitigations
• Security: (notes)

  Installing and loading package providers -- how do we make sure that providers are safe and secure to install. What happens if a provider is installed un-elevated and then used elevated? Should providers require elevation (my thoughts are no)

New To Try

• Bootstrapping off the web

Package Provider Writing Online Workshop (11:30PST -> 3:00PST)

• Provider SDK samples (in C# and PowerShell )
• Will keep the conference call open all afternoon to help anyone writing a provider.

When will regular expression support be available?

Currently, only Chocolatey is supported as a provider in Add-PackageSource, but there is no mention of this when the command fails due to an 'unknown provider'. By using [ValidateSet('Chocolatey')] with the Provider parameter an error would still be thrown, but it would then list out what the possible values are allowed. This would also help with tab completion by cycling through the possible provider values when using this command.