projectile-consult does not byte-compile without consult

[marienz]

The projectile-consult module added in 0fe44ed is intended as a "soft dependency" on consult by not having Projectile's core load it, but build systems don't understand this: they attempt to byte-compile the new file along with the rest of Projectile as defined by its MELPA package, which fails without consult present. This can result in a noisy warning (package.el, which pops up a *Compile-Log* buffer but still installs the package) or outright failure (nixpkgs, see nix-community/emacs-overlay#544).

Would you consider either:

• Making projectile-consult.el byte-compile without consult present? I took a stab at this in https://github.com/marienz/projectile/tree/optional-consult: happy to send that (or a different approach if you suggest one) as a PR.
• Excluding projectile.consult.el from Projectile's MELPA package / recipe, and adding a separate MELPA package for it?
• (Or some other solution...)

[otavio]

Confirming this still breaks downstream builds: on a NixOS/home-manager config using nix-community/emacs-overlay, the latest projectile (20260627.907) fails native-compilation outright:

emacs-projectile> Compiling .../projectile-consult.el...
emacs-projectile> Error: file-missing ("Cannot open load file" "No such file or directory" "consult")
emacs-projectile>   require(consult)

Because the emacs build is a dependency of the whole system closure, this is a hard failure (not just a noisy *Compile-Log*), so it takes the entire NixOS/home-manager build down with it — same root cause as nix-community/emacs-overlay#544.

The optional-consult approach (making projectile-consult.el byte-compile cleanly without consult present, e.g. declare-function + a deferred require at call time) would fix this for every build system that compiles the whole MELPA package, and preserves the intended soft-dependency. +1 to @marienz sending that as a PR.

For anyone hitting this before it's resolved upstream, an emacs-overlay-side workaround is to add consult to projectile's packageRequires via an overlay so the optional file finds it at build time.

[bbatsov]

My bad! I'll address this problem later today.

I took a shortcut with the packaging of projectile-consult as I was wondering whether to make it a separate package like helm-projectile, but I still have to decide about the optimal packaging approach in general. I guess you noticed that now Projectile bundles async project indexers, but one still needs some async-aware UI for those and Consult seemed like a better choice than re-inventing the UI layer.