@Sigma's answer is a good start, but it doesn't filter by executability, nor does it allow for extra suffixes. On windows, for example, running a can invoke a.exe, if that's what's in your path.
So use executable-find; here's the definition (taken from Emacs' sources), if you're curious:
(defun executable-find (command)
"Search for COMMAND in `exec-path'...
require is not meant to avoid recusive loading, it is meant to avoid repetitive loading. So no, it does not solve you problem here.
About the problem
The right way to approach this (in my opinion) would be to avoid the
The test1 file in your example has no reason to require test2.
Even if that's not true for your actual ...
Without using cask or pallet, you can achieve this with code such as the following:
(setq package-user-dir (expand-file-name (concat "elpa/" emacs-version) user-emacs-directory))
(setq package-enable-at-startup nil)
(defun require-package (package &optional min-version no-refresh)
"Install given PACKAGE, optionally requiring MIN-...
Package.el is a builtin package manager that can be used to install emacs packages.
Cask is an Emacs Lisp project management tool, similar to Maven or Leiningen. It aims to control and automate the entire life cycle of an Emacs Lisp package, including dependency management, packaging, distribution and testing. You can use Cask to manage your emacs your ...
Your example is weird:
You require test2 at the end of test1, whereas require should "always" be at the beginning of a file.
Your test1 does not call any test2 functions, so it doesn't need test2 to work (hence it requires it, unnecessarily), and OTOH your test2 does call test1 functions, so it does need test1, yet it fails to require it.
IOW, you have ...
The manual suggests adding declare-function and defvar lines.
The resulting test2 file is:
;;; test2.el ---
(declare-function test-fun1 "./test1.el")
(defun test-fun2 ()
(let ((test test-var1))
;;; test2.el ends here
However, this needs to be done for all functions and all ...
If the package has its dependencies properly declared,cask install should do all the setup that is necessary. Cask then builds the load-path automatically for you so that (require ...) statements resolve when you invoke cask exec.
Interactively evaluation / development of a package with cask-installed dependencies seems to be a shortcoming of Cask. Four ...
I'm not sure wether cask really rewrites the Cask file, cause I have two (independent) installations, that both have missing entries in the Cask-file that are nevertheless installed in the .cask folder.
Since I'm not really an elisp hacker (but try to become one), for now I only have a tcl script that writes out a Cask files that mirrors the current ...
My understanding of the way pallet works is that it looks at your currently installed list of packages and writes out the Cask file accordingly.
So, it's not as if in the intervening time any package installs or removals won't be tracked, since when pallet is initialized it says "What packages are installed NOW".