Pitch: [Optionally] Limiting the output of `swiftly list-available`

Hello folks,

The swiftly list-available command can output a huge list of toolchains, especially with the main-snapshot label identifier.

I personally tend to do a swiftly list-available main-snapshot | head, however I'm considering a feature in swiftly that would limit the number of toolchain returned by swiftly list-available

I would like to know what the community likes here.

I see a couple options:

  1. Add a --show-all flag

    This option changes the default behaviour of the command by limiting the number of returned versions. If there are more versions than displayed, a message is emitted on the console informing the user.

    The user can pass --show-all list all current versions

  2. add a --limit <number> option

    The --limit <number> indicates the maximum number of items to return. If not provided, list all versions.

    This preserves the current behaviour while providing additional functionality.

Do folks think this is useful? If so, which option would be ideal? Are there other options?

Cheers,

Sam

1 Like

I'm interested to hear feedback from others in the community.

I tend to default on the side of the "Unix philosophy" (if there is such a thing) unless there is a clear problem with it. swiftly isn't a pager and there are good tools for paging and limiting on Unixes, such as more/less/head/tail that are in common use. Tools like more/less can know what your terminal height is and make adjustments tailored for your environment.

Performance can be a reason for a tool to take on its own paging responsibilities since it knows the dynamics of the underlying database. In this case the swift.org API is heavily cached by CDN's and seems to be very fast in general. I don't think that this really applies here.

However, the snapshot list, especially for something like main-snapshot is immense, and ever growing. Same with the released toolchains for macOS. More will be in the same situation over time, although it will take longer to get really out of control. Practically speaking, many of these toolchains aren't useful anymore since they might require very old versions of macOS, or Linux distributions that are no longer supported by their vendor.

What if we looked at this problem in terms of managing the volume toolchains that are no longer practical for anyone to use? For example, main-snapshot toolchains that led up to releases from long ago are probably interchangeable with the actual release from that time, so they should be excluded from the default list. Also, releases that are no longer supportable in the environment that they must run, such as Linux distributions that are out of LTS or macOS beyond a certain epoch, shouldn't be shown either because virtually nobody will use them.

So, a variation of the first proposal is to establish various sorts of limits that exclude various toolchains that are of very limited use, and add a --show-all flag for archeological digs. It wouldn't be based on a static (or user specified) limit in terms of number, but filtered based on practical use of each toolchain in the list.

Chris

2 Likes

I think it'd be great if swiftly allowed something like swiftly list-available main-snapshot-2026 (and main-snapshot-2026-07, of course.) I just intuitively assumed it would work, but it turns out it doesn't (related swiftly source code).

Limiting number of results may have different use cases too, but I think allowing filtering by year/month is a behavior that's reasonable for many users to expect but currently missing, and can also solve the problem of 600+ lines of main-snapshot list output.