Agreed, namespace clashes are an obvious problem. "My program that worked last week now crashes? Oh, it's because I apt-get installed something completely unrelated."

Well, (use :as) fixes that one.

Namespaces are a honking great idea, let's have more of those!

Also, I think I just realized an another problem -- if I understood the lib correctly, it scans through the PATH once at require time. This is bad, because Clojure is often deployed in places where processes run for very long times. Even things as immutable as tools in PATH can change when given long enough time.

There's no (use :as), only require. (require [shake.core :as sh])

That's a step in the right direction, but it still triggers tons of warnings replacing vars in clojure.core.

use does accept an :as option:

    => (use '[clojure.set :as set])
    => set/intersection
    #<set$intersection clojure.set$intersection@58ca40be>

Prior to the addition of :refer to require, this was often paired with an :only (...) in order to alias a namespace as well as refer in some limited set of vars if desired, all in one declaration.

Huh, I checked the docs before I commented. It is indistinguishable from require :as, thought, right?

As far as I know. Honestly, by use/require/refer-fu is not very strong, I always just use the ns macro.

Yes, the :as option is the same whether you use it with require or use.

I'm also looking for better ways to index path. If I can pass some options in (use) and initialize with options, it will be better.

I really think "not indexing path" is the better choice. Instead of (uname -a), why not just export a single symbol and do (shake uname -a)? (or even just (sh uname -a)?) Then find the correct program to run at invocation time. It's more clear about what happens, and allows much simpler implementations with much less weird failure modes.