---

2.5.2.1 Use existing libraries where possible

If you look at Quicklisp, you’ll quickly notice that

• the client does not rely on any third party code and
• all functionality, from an HTTP client to untaring,
• are implemented completely as part of the Quicklisp client project.

The upsides of this strategy are that

• only required functionality is loaded into the development image,
• it prevents version conflicts between code the Quicklisp client depends on and the code you’re developing depends on, and
• it helps ensure that Quicklisp works on a broad set of Common Lisp implementations.

However, it has a major downside:

• the maintenance and development costs of the project manager are high,
• potentially making it difficult to implement new features and
• the project manager does not really drive the quality of code in the community at large higher.

CLPM Uses Existing Libraries for Core

The desire to use existing libraries drives the decision for the CLPM core and client to be separated. The client has no external dependencies outside of ASDF/UIOP, which allows it to share all the benefits of Quicklisp’s model, and the core never needs to be loaded into a development image, so it can leverage any dependency that makes sense without impacting the development image in the slightest.