# scoop-directory indexes the Scoop ecosystem, and ScoopSearch has taken over

> scoop-directory crawls GitHub for Scoop buckets and publishes a static directory and search index covering over 25,000 manifests in over 900 buckets, rebuilt daily at 15:00 UTC. The README is explicit that ScoopSearch is now the official search engine chosen by the community, so this project is best read as the still running infrastructure that the community handed over.

**rasa/scoop-directory** — A searchable directory of buckets for the scoop package manager for Windows

- Repository: https://github.com/rasa/scoop-directory
- Website: https://rasa.github.io/scoop-directory/
- Stars: 930 · Forks: 80
- Language: Python
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/rasa-scoop-directory

## What the index covers and how fresh it is

The purpose is narrow and concrete: it is a searchable directory of buckets for the Scoop package manager on Windows.
The scale is stated in the README. The search index contains over 25,000 application manifests in over 900 buckets, and it is updated daily at 15:00 UTC. For comparison, the README describes ScoopSearch as searching over 152,000 application manifests in over 1,300 buckets.
An important detail for anyone using Scoop on Windows: a manifest is a JSON file describing where a release can be downloaded and how it is installed. Scoop itself only knows about the buckets you have added. This directory exists because the ecosystem of third party buckets grew far beyond what any one person could track, and searching across them was the missing piece.
The audience is Windows developers and administrators who install command line tools without an administrator account, and who want to find out whether a package exists somewhere in the bucket ecosystem before writing their own manifest.
The site is published at https://rasa.github.io/scoop-directory/ with a search page at /scoop-directory/search, and the repository is MIT licensed with the author listed as rasa.

## The static views are what make the directory useful without the search box

Beyond the search interface, the directory publishes a set of Markdown listings that are regenerated from the index, and they are sorted in several different ways.
There is a listing by bucket name, one by application, one by stars, one by forks, and one by last updated. Each corresponds to a file in the repository, by-bucket.md, by-apps.md, by-stars.md, by-forks.md and by-date-updated.md.
The by-date-updated view is the most operationally useful one. When a bucket goes stale, or a new package appears that you have not seen before, scanning a sorted list of recent activity tells you what changed and which bucket to add. The by-stars and by-forks views are popularity signals, and they are also the views where it is easiest to draw the wrong conclusion, because a bucket with many stars is a bucket people have heard of, not a bucket that is maintained.
The by-score listing exists but is marked as currently deprecated, which means the composite ranking that the site once computed is no longer being updated.
Each of those Markdown files is served as a page of the same static site, built with Jekyll conventions. The repository holds _config.yml and search.html, and a search.html at the root is the page that powers the search interface, put together by @rashil2000 according to the README.

## Discovery through the GitHub search API, and the two files that override it

Buckets are found by crawling GitHub, and the mechanism has a failure mode that the README documents explicitly.
If GitHub fails to discover a bucket through its search API function, the bucket URL can be added manually to include.txt. That file is the escape hatch for a bucket that exists but was not found, for example because it is not named the way the search expects or because it is new.
In the other direction, exclude.txt removes buckets that duplicate other buckets. The README notes that this list used to live inside the maintenance/github-crawler.py script and was migrated into its own file, which is a small but telling change. Moving policy out of code means a person can adjust it without touching the crawler.
The crawler itself lives in the maintenance/ directory, and the repository history shows the project started as a fork of awesome-scoop by Tapan Nallan, which was originally a hand maintained list. The automated index replaced that list.
Two files and one Python crawler is the entire mechanism behind the 25,000 manifests. The index is therefore as good as the GitHub search API and the two lists, which is a real constraint when you consider what happens to a bucket that is renamed or made private.

## The Makefile fetches the schema and the licence data the crawler validates against

The build side is small and declarative, and it explains how the index knows what a manifest should look like.
```bash
update:
	-mkdir -p vendor/ScoopInstaller/Scoop
	wget -O vendor/ScoopInstaller/Scoop/schema.json $(SCOOP_SCHEMA_JSON)
	wget -O vendor/ScoopInstaller/Scoop/buckets.json $(BUCKETS_JSON)
	-mkdir -p vendor/spdx/license-list-data/json
	wget -O vendor/spdx/license-list-data/json/licenses.json $(LICENSES_JSON)
	wget -O vendor/spdx/license-list-data/json/exceptions.json $(EXCEPTIONS_JSON)
```
Four URLs feed the pipeline. The schema is the JSON schema that Scoop publishes for its manifests, so a manifest that does not conform is a manifest the crawler can flag. The buckets list gives the known official buckets. The last two come from the SPDX licence list data, the licences and exceptions JSON files, which is how the index can record the licence of each application.
The licence data is vendored into the repository rather than fetched at crawl time, and there are two Makefile targets for managing that subtree.
```bash
add:
	# git remote add -f spdx/license-list-data https://github.com/spdx/license-list-data
	# git subtree add --prefix vendor/spdx/license-list-data spdx/license-list-data master --squash

pull:
	# git fetch spdx/license-list-data master
	# git subtree pull --prefix vendor/spdx/license-list-data spdx/license-list-data master --squash
```
The vendor/ directory at the root of the tree is where that subtree lands. Vendoring rather than querying at runtime means the licence data is pinned to a known revision, which is the right call for reproducibility and the wrong one for freshness, since the index inherits the age of the vendored snapshot until a pull runs.

## The Python side: pandas, GitPython and a JSON schema check

The crawler is Python, and the dependency list is short enough to read in one pass.
```bash
chardet==5.2.0
GitPython==3.1.43
Jinja2==3.1.4
jsoncomment==0.4.2
jsonschema==4.23.0
markupsafe==2.1.5
pandas==2.2.2
requests==2.32.3
setuptools==71.1.0
```
Every dependency is pinned to an exact version, which for a crawler that runs unattended on a schedule is the correct level of strictness.
GitPython handles cloning and reading the bucket repositories, requests handles the GitHub API calls and the raw file downloads, and chardet deals with encoding detection on files that were not written as UTF-8. jsonschema validates manifests against the Scoop schema that the Makefile downloads, and jsoncomment strips comments out of JSON files that a tool otherwise would not parse. Jinja2 renders the output pages and pandas does the tabular work behind the sorted listings and the database.
The output database, scoop_directory.db, is checked into the repository, and the README points to a downloadable copy of it in the crawl-scoop-directory project, which is what the scoop-search command line tool by @zhoujin7 uses.
Style is handled by black with a line length of 132 and a target version of py37, configured in pyproject.toml, and there are separate CI workflows for the index update, a linter, and black itself, plus an AppVeyor build.

## ScoopSearch won, and the alternatives split by scope

The first note in the README is the one to read before anything else. ScoopSearch is now the official search engine for Scoop, as chosen by the community in the Scoop issue tracker. Please consider using it for searching. Scoop Directory will continue to be available for the foreseeable future, but development efforts will be focused on ScoopSearch.
That is a handover rather than a shutdown, and it explains the current state of the repository, where the last push was on 2026-10-19 and the index still updates daily at 15:00 UTC. There are no GitHub releases, which is normal for a repository whose output is a continuously regenerated website rather than a versioned artefact.
The README also catalogs the alternatives, and they differ in scope rather than in quality.
On the web, ScoopSearch covers the largest index. Repology searches the Main, Extras, Versions and Games buckets and can also search Chocolatey, Winget, Baulk and Npackd, which makes it the tool to use if you want to compare the same application across package managers.
On the command line the options divide sharply. shovel.sh searches only the known buckets. scoop-search by @zhoujin7 searches the buckets found by scoop-directory and works with crawl-scoop-directory, which compiles a Sqlite3 database. scoop-search by @shilangyu is installed with scoop install scoop-search and searches the buckets you have added locally with scoop bucket add. scoop-search-multisource by @plicit searches both local buckets and the ones scoop-directory finds. And scoop-sd by @grisha765 is powered by scoopsearch.github.io.

## Conclusion

Adopt ScoopSearch rather than scoop-directory for searching Scoop packages, since the community chose it as the official search engine and the README says development effort will focus there. Keep scoop-directory in mind if you need its static views, such as the by-bucket, by-apps and by-date-updated listings, or the scoop_directory.db database. Before relying on it, check that the bucket you need appears in the index, and add its URL to include.txt if the GitHub search API did not discover it.

## FAQ

### What is scoop-directory and how large is its index?

It is a searchable directory of buckets for the Scoop package manager on Windows. The README states that the search index contains over 25,000 application manifests in over 900 buckets and is updated daily at 15:00 UTC.

### Is Scoop Directory still the recommended way to search for Scoop packages?

No. The README states that ScoopSearch is now the official search engine for Scoop as chosen by the community, and that development efforts will be focused on ScoopSearch, while Scoop Directory will continue to be available for the foreseeable future.

### How do I add a bucket that the index did not discover?

If GitHub fails to discover a bucket through its search API, you can add the bucket URL manually to include.txt in the repository. A separate exclude.txt removes buckets that duplicate others.

### What does scoop-directory use to validate the manifests it indexes?

The Makefile downloads the manifest schema and buckets list published by ScoopInstaller, plus the SPDX licence list and exceptions JSON files, into the vendor directory. The Python side uses jsonschema against that schema.

### Can I search Scoop packages from the command line?

The README lists several options. shovel.sh searches the known buckets, scoop-search by @zhoujin7 searches the buckets found by scoop-directory and works with a downloadable Sqlite3 database, and scoop-search by @shilangyu can be installed with scoop install scoop-search to search your locally added buckets.

## Sources

- [Issues](https://github.com/rasa/scoop-directory/issues)
- [License: MIT](https://github.com/rasa/scoop-directory/blob/master/LICENSE)
- [Project website](https://rasa.github.io/scoop-directory/)
- [rasa/scoop-directory on GitHub](https://github.com/rasa/scoop-directory)
- [README](https://github.com/rasa/scoop-directory/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rasa-scoop-directory