Choco: Change default 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?

[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]

:+1:

[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.

[markekraus]

How about add a choco listlocal and choco listremote and then add a new option to choco list to be like choco list --default-source=local. Then when you release a major version with other breaking changes you can alter the default behavior of choco list. This will allow you to implement now and break later.

[vexx32]

Yeah that, thanks @markekraus 😄

[ExE-Boss]

You could use a use‑beta‑cli config option, like what pnpm does.