On 10/30/2013 04:52 PM, Zach Beane wrote:

Jeffrey Cunningham <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