Comments on: Packages organization and exporting symbols

By: Jorge Tavares

Jorge Tavares — Wed, 09 Nov 2011 07:48:51 +0000

Hi Didier,

I like your suggestion! I will implement it and give it a try. Thanks! :-)

By: Didier Verna

Didier Verna — Tue, 08 Nov 2011 20:17:18 +0000

In fact, what you can do is keep your automatic find-and-re-export process, but use it to actually generate the main package file (or part of it). You can then run your script on a regular basis (or say, after each commit to your repo) to maintain an up-to-date version.

I think this is a win-win situation because you keep the automation and yet, you also have the explicit file that your users can browse.

By: Jorge Tavares

Jorge Tavares — Tue, 08 Nov 2011 19:58:22 +0000

Hi Zach,

That’s a very good point! In fact, my first solution was copying all the symbols to the export list of the main defpackage. However, I thought it could lead me to some mistakes and the hassle. That’s why I thought the described approach was cool. But I see your point and to look at a single file with all the export symbols is really a big plus. As a middle ground, perhaps putting all the defpackage forms in a single file and do the “automatic” export at the end of it and documenting it can be an alternative. That way the exports lists are all together (in spite of not being a single one).

I need to think better about this… :-)

By: xach (@xach)

xach (@xach) — Tue, 08 Nov 2011 18:44:25 +0000

I find I generally dislike establishing package structure this way. I’d rather see explicit import & export lists in a defpackage form, in a single place. If a user wants to find out what the exports are to e.g. figure out if there might be a conflict, they have to load your code first, or go through N different defpackage forms. This might be easy or hard depending on how scattered the defpackage forms are.

Creating the export lists and maintaining them can be a hassle, but I prefer to undertake that hassle for the benefit of users (myself included).