These are chat archives for chocolatey/chocolatey-oneget

30th
Mar 2016
jdemate
@jdemate
Mar 30 2016 17:46
Is there a equivalent command in One Get to 'choco upgrade'? My organization wants to run 'choco upgrade all' each month and I am trying to decide if PackageManagement is enough or if I will have to deploy choco.exe.
Darwin
@DarwinJS
Mar 30 2016 19:02
@jdemate - packagemangement uses "install-package" for upgrades. Technically this should work 'Get-Package -provider Chocolatey | Install-Package -provider Chocolatey' - but in testing it does not. This seems to work: 'get-package -provider chocolatey | %{install-package $_.name -provider chocolatey}'
However, I'm not sure what happens if dependencies are upgraded first. So sorting might help, like this:
get-package -provider chocolatey | sort name | %{install-package $_.name -provider chocolatey}
You can test by first installing an older version of notepadplusplus: 'install-package notepadplusplus -MaximumVersion 6.8.8 -provider chocolatey'
Now that you know how to do it I have to say I would never use PackageManagement for Chocolatey in it's current form. Wait until Rob has at least his first release out. Also DO NOT try to use both clients on the same packages.
jdemate
@jdemate
Mar 30 2016 19:37
@DarwinJS thanks for the reply. I had assumed install-package would also upgrade, but hadn't found that in writing yet. Thanks for verifying.
I read in the chocolatey FAQ that Rob is pushing people away from PackageManagement because it is "based on 2 year old Chocolatey technology". Can you tell me a couple good compelling reasons why you "would never use" PackageManagement? The FAQ only mentions security. I have built my own nuget repo that sits on my intranet and personally packaged each choco package on it. I have not had any issues installing with the PackageManagement module to date. However it is certainly possible that I am missing something.
Darwin
@DarwinJS
Mar 30 2016 19:39
Specifically "would never use... in it's current form"
I am pretty sure -params won't work - unless you can enlighten me.
Same with all the other cool choco parameters like -ia
Darwin
@DarwinJS
Mar 30 2016 19:45
Also the code for processing packages is 2 years old - so if you happen to use anything newer in your packages, it won't float
This might not affect you and is actually more about whether you can use Package Management everywhere, but...
Server 2008 R2 (Win7) and later require first WMF 4 and then they can install WMF 5. Also requires .NET 4.51 versus choco's .NET 4.0
So if you have old server code (like I've seen at many customer's shops) coming all the way up to .NET 4.5 might be a no go.
If you're servicing Win7 Desktops - especially a large fleet above 10,000 - that might be a lot of PowerShell updating just to get using your new packaging.
Darwin
@DarwinJS
Mar 30 2016 19:51
The "-params" and "-ia" may not be a big deal if all your packages are hard coded to one set of values and you don't curate anything from chocolatey.org - but where I am, if I can copy a chocolatey.org package into my private repo without making changes to it - that probably means I can keep "re-curating" that same package without having to maintain it myself.
Another one that might not affect you is the ability to use chocolatey DIRECTLY in CMD, Ruby, Python, etc, etc - without having to invoke PowerShell. Many times invoking PowerShell by these other environments is simple, but sometimes being able to do it directly is an important differentiation.
Rob Reynolds
@ferventcoder
Mar 30 2016 20:15
@jdemate I said I'd recommend not using one get chocolatey provider until we announce an official release
jdemate
@jdemate
Mar 30 2016 20:15
My current setup is just used to deploy servers. I use DSC to do all the heavy lifting and found that it was missing a software installation component. Chocolatey filled that hole nicely. WMF 5 has lots of important DSC features that made me jump on that bandwagon early and the inclusion of PackageManagement was a nice side effect. So I wrote a DSC resource around the PackageManagement module and that has been working well. Now other teams are beginning to take notice and I was asked to open it up to a wider audience. Client systems is a possibility. I know the current PackageManagement Preview runs on WMF 3 & 4, but hadn't noticed that it required .net 4.5. Thanks for pointing that out. Also the lack of parameters was annoying. One package I had to create twice just to support two different argument sets.
I am currently in the process of turning my chocolatey nuget server into a gallery server. Once I make it available to everyone it will certainly take on a life of its own. So I want to make sure that I point folks to the right client tools. All your points are going into my FAQ. Thanks for that!
Last item I will bug you about is timeframe. Any idea when the official release will be available?
Rob Reynolds
@ferventcoder
Mar 30 2016 20:16
Use PackageManagement/OneGet for others things just not the choco provider
Darwin
@DarwinJS
Mar 30 2016 20:18
@jdemate - Rob brings up a good point - packagemanagement will be required for other frameworks. Do a "Find-PackageProvider" to see a new container provider and office 365 provider.
WMF 4 requires .NET 4.5.1 and WMF 5 does not raise the bar any higher
Also you might want to think of using the free version of ProGet or Nexus Repository instead of cooking your own server
I package the new beta version of nexus respository 3.0.0-m7 - nice enhanced support for NuGet.
You must use "choco install nexus-repository -pre" to get the prerelease 3.x stuff
Downside is the Nexus gallery looks nothing like nuget.org or chocolatey.org where ProGet's looks very close.
Gary Ewan Park
@gep13
Mar 30 2016 20:32
@DarwinJS should your Choco package point to here: http://www.sonatype.com/nexus-repository-oss rather than here: http://www.sonatype.com/nexus-repository-sonatype
also, while you are here, did you see my comment a while back about changing the shim name for your .Net Version Checker Package?
Darwin
@DarwinJS
Mar 30 2016 20:34
@gep13 - @ferventcoder 0 helped me find the 3.0.0 url actually - don't ever remember seeing the one you just cited - so maybe new?
Was the comment here or on the package?
No, wait, wait it's my turn....
I take PR's on my packages ;)
Gary Ewan Park
@gep13
Mar 30 2016 20:35
could be, I have never been on the site before, so way just stumbling through the site, looks for pricing and then I saw the one I linked to
Darwin
@DarwinJS
Mar 30 2016 20:35
LOL! - direct me to the comment and I'll take a look.
Gary Ewan Park
@gep13
Mar 30 2016 20:35
hmm, I think it was on here, two secs...
Darwin
@DarwinJS
Mar 30 2016 20:35
I can't keep up with the volume here - sorry.
Gary Ewan Park
@gep13
Mar 30 2016 20:42
@DarwinJS no, sorry, can't find it. It was basically a suggestion to change the shim that you create in the .Net Version Checker away from dotnet. With the upcomgin release of the dotnet cli, there will be a conflict for people who have both installed
Darwin
@DarwinJS
Mar 30 2016 20:47
@jdemate - to be very clear - it is ONLY Windows 7 and Server 2008 R2 that must install WMF 4 before going to 5. New versions of Windows can apply WMF 5 directly.
@gep13 - so you are suggesting I rename the default name of the EXE? Makes sense.
Gary Ewan Park
@gep13
Mar 30 2016 20:49
@DarwinJS oh, sorry, I thought you were creating a shim. I didn't realise that this was the actual name of the exe
that makes things harder
the ideal would be to have the author rename the exe name, but not sure how likely that would be to happen
Darwin
@DarwinJS
Mar 30 2016 20:50
@jdemate - are you supporting servers that are in part of a Continuous Delivery pipeline (constant code being deployed to them?) - or Traditional Ops - servers in an internal company infrastructure?
It would be just a rename
Probably needs a GUI shim too - realized another of my packages does
Gary Ewan Park
@gep13
Mar 30 2016 20:56
:+1: