Change behavior of choco list to be local only

[findel]

The current default behaviour of choco list (or clist) is to list ALL of the packages available on chocolatey (currently 2596 in total). This is a little slow, and not really helpful as a default.

Couldn't the default behavior be to display "local only" packages, displaying only packages that are installed locally, as when you do choco list --localonly?

Then require switches to get data from the repositories, rather than the other way around?

Implementation Notes

When this work is undertaken, the deprecation notices that were add in this PR will need to be reviewed/removed:

#2626

[ferventcoder]

I love the idea of this - I want to get an idea of what it may require from other tools as this would be a breaking change.

[alexchandel]

choco list should absolutely list only locally installed packages by default. We already have choco search with no arguments to list ALL packages.

[ferventcoder]

Search and list are aliases

[darrelmiller]

👍

[christianrondeau]

Agreed on list being --localonly by default, and maybe search could not be an alias anymore? I also thought that search was server-based, and list was not. It may be interesting to run a quick survey if you're not sure.

[alexchandel]

@christianrondeau I would instinctively assume list was local only, and only listed packages installed by default.

@ferventcoder Can this please happen in 0.9.9.7? It's intuitive (list gives your packages, search without any filter gives all packages), it parallels the behavior of other package managers, and it has broad support. It's a breaking change, but it affects users who are exploring chocolatey packages, not scripts (compare with choco install), so its impact is limited.

[ferventcoder]

@alexchandel it's intuitive for you but it is a breaking change, so that's why the milestone is 1.0.0. Folks need time to prepare for the break.

[ferventcoder]

@alexchandel and it is used by applications that are building on top of chocolatey.

[alexchandel]

@ferventcoder Is there any application known to use choco list instead of choco search, besides possibly ChocolateyGUI?

[ferventcoder]

puppet choco provider / chef cookbook / boxstarter

[alexchandel]

@ferventcoder So from what I saw, the three packages you mentioned all use choco list for local searches already (I should've specified that!) and won't be affected by this change. So it should be reasonably safe to implement.

[RichiCoder1]

@gep13 Does this break us with new provider? I know the old one used OData directly.

[ferventcoder]

@RichiCoder1 maybe? It is going to follow a semver break boundary, likely v1.

[RichiCoder1]

If that's the case, then we'll probably have fixed the gui to use chocolib by then and it'll be a non-issue.

[gep13]

@RichiCoder1 yes, we are likely to run into some issues with this. But as you say, switching to the use of the lib will ultimately be the correct path forward.

[alexchandel]

@ferventcoder Can this please happen? I ended up with a corrupted XML settings file after I had to Control+C to stop an accidental choco list from wasting 5 minutes.

[ferventcoder]

@alexchandel Absolutely. Note that we've already set a milestone and version for this.

[vexx32]

A milestone is great, but do we have a timeline on where it falls along that path, or a release timeline up to 1.0 somewhere?

EDIT: Especially since this particular issue has been open for... coming up on 4 years now?

[ferventcoder]

@vexx32 understand the timings are slower than you might like, but it's something that must be moved and transitioned on slowly - otherwise we break many things (and it's likely we would anyway because sometimes folks don't read, but at least they've had the potential to do so).

[vexx32]

@ferventcoder I'm merely commenting on the timeline because most products have a fairly regular breaking changes pattern that is well fleshed out, and also because a target without a set date tends to get forgotten very quickly.

As a handful of the folks in the PowerShell slack/discord mentioned, it might be worth implementing it as a optional configurable feature first; that way it won't break anything in its default configuration. If we also are able to track in some unobtrusive method which features like this are being used and on what % of machines, we can then look at defining more concrete timeline of swapping which is default, and eventually deprecating the lesser-used option if it falls out of use.

[vexx32]

After some internal discussion with the team, we've decided to go ahead with ignoring --local-only and related arguments (-li, etc) for choco list. There will be a warning outputted to the log file only, but not emitted to output / the console.

[choco-bot]

🎉 This issue has been resolved in version 2.0.0 🎉

The release is available on:

• GitHub Release
• Chocolatey Package

Your GitReleaseManager bot 📦🚀

[ethanbergstrom]

It looks like the Chocolatey team went back on the understanding we had in this thread, where --local-only would be parsed but ignored.

I tried to create a seamless experience for the users of my scripts to maintain a level of passivity, but that all seems to have been for naught.

Very disappointing for a piece of software designed to make the lives of Operations folks easier.

Strike that - my apologies. Looks like list --local-only still works if combined with --limit-output so that will work for the time being.

[pauby]

If you are using --limit-output or -r (which is designed for automations and computer readable output) nothing changes. Automations and scripts will continue to run with only a warning added to the logs.

If you are a user at the desktop running choco list --local-only then you'll get an error. As you're being interactive, that's easy enough to correct.

See the upgrade guide.

Note that the discussion to add the exception for --limit-output and -r was wholly started from this thread, so I'm disappointed that you suggested we had ignored it!

EDIT: Just noted you'd updated your comment. Glad it's working for you. Feel free to ignore parts of the above 😄