The quicklisp/local-projects/ directory is just one convenient place to put stuff, nothing dictates that you have to put it there.
You can also put your own .asd systems elsewhere and set up a call to:
(pushnew ".../my-projects/" ql:*local-project-directories* :test #'string-equal) (ql:register-local-projects)
Yes, you have to evaluate these two lines after making a new .asd file. But if you put all your projects under ".../my-projects/" then nothing else has to change so it can be part of a standard thingie you just call after setting up a new experimental project.
On Wed, Oct 30, 2013 at 8:26 PM, Jeffrey Cunningham < jeffrey@jkcunningham.com> wrote:
On 10/30/2013 04:52 PM, Zach Beane wrote:
Jeffrey Cunningham jeffrey@jkcunningham.com jeffrey@jkcunningham.com writes:
But what about the very common (for me, at least) case where I want to experiment around with some code that is not intended to go in a package.
One option is to learn a different way. I start almost every experiment with the three-file system of foo.asd, package.lisp, and foo.lisp, which makes it and its dependencies trivially quickloadable. And the experiments often grow into something I want to save for easy reuse.
I'm fine with learning a different way. Actually, I experimented with your quickproject utility when you first released it. I like the idea of it. But the single significant drawback for me is that it seems to require project files to be located to suit the needs of the tool rather than the needs of (for me) the work. If I'm contracting for companyX their files all go somewhere within a companyX folder. Their data goes there. Their docs. Everything. I can tarball the whole thing up and send it to them. I can archive it. I can send it to Richard Snowden. Whatever. It seems to me that the requirements of the package methodology you are suggesting requires that I either do my contract work in subdirectories of the quicklisp folder of some other standard ASD visible folder, or be continually modifying the ASD paths so the loader knows where to find them. Maybe I haven't just wrapped my head around it right, but it seems odd to have to build a package just to load some other packages and use them.
I agree that many, many times what started out experimental developed into a package I've reused for other projects. I think if I could figure out how to keep files organized by job rather than by tool I'd be all for your idea.
--Jeff