Wildcard modules support

[Faré]

wild-modules were an example extension and/or contrib from the asdf 1
days. There is a test for them in test/ but otherwise I don't believe
anyone uses them. If you have the asdf git installed, you can use them
with package-inferred-system.

I believe that package-inferred-system is a better way to achieve a
similar effect, that allows for dependencies between sub-systems,
unlike wild-modules. I suppose a wildcard option to load all files in
a directory while using package-inferred-system dependencies would be
a nice feature to add. But so far, I found it more practical to have
an explicit file named "all.lisp" that includes all the files that
matter.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Quality means doing it right when no one is looking. — Henry Ford
Morality means doing the right thing when no one is looking. — Jan Krepelka


On Fri, Jun 24, 2016 at 1:44 PM, Robert Goldman <rpgoldman at sift.net> wrote:
> On 6/24/16 Jun 24 -12:31 PM, rcn wrote:
>> Hi all,
>>
>> Will wild-module support ever be fully and "officially" supported?
>>
>> Currently there's what appears to be a sample implementation as part of
>> asdf/contrib but, if I recall correctly, asdf/contrib is bound to
>> disappear eventually (actually, the documentation says this is an empty
>> package). However, it's not clear how to use it, it's not documented and
>> it's not clear if it will ever be a part of asdf or not.
>>
>> In my mind, this is an useful feature. Not for small systems (which,
>> sadly, are the majority of Common Lisp open source projects), but for
>> large systems where new files may be added to a directory to incorporate
>> additional functionalities (a plug-in kind of thing).
>>
>> In these scenarios, wild-module definitions would ease development and
>> system maintenance greatly. As far as I know, asdf is perfectly capable
>> of implementing it and it looks to me like an implementation-agnostic
>> feature, so I see no reason not to include as a core component.
>
> AFAICT, wild-modules are completely undocumented and, since I wasn't
> involved in their development, I don't understand what they are for, or
> what they are supposed to do.  There are neither docstrings nor comments.
>
> I also note that the code in contrib is more than 3 years old, so likely
> doesn't even work.
>
> So I am not in a position to answer your question (except by saying "WTF
> is a wild module?").
>
> In order to move towards integration, I would like to see some kind of
> specification to describe the intended function of WILD-MODULE, and how
> we intend to meet the specification.
>
> Then we could move forward with getting the code integrated, and some
> appropriate documentation into the manual.  A test suite would also be
> required before we could "ship" WILD-MODULEs.
>
> Best,
> r
>
>
>