Am 17.01.2019 um 08:57 schrieb Riccardo (Jack) Lucchetti:
On Tue, 15 Jan 2019, Sven Schreiber wrote:
>> Interesting. But I think what you're describing could be done just in
>> memory, without writing a temporary package file. The idea would be:
>>
>> 1) Load A.gfn as usual, detect deep-dependency on B.
>> 2) Load B.gfn in a (new) "merge mode", whereby its public functions
>> and added to A's public list and its private functions to A's private
>> list. So package B is not really loaded as such, its content is just
>> merged into that of A on the fly.
>>
>> A.gfn and B.gfn on disk would not be affected.
>
> If that's easy internally, it sounds quite nice, yes.
I've marked the relevant GUI string for translation. I believe we should
update the packages tex file on this, which is quite important.
Yes. OTOH maybe some "secret" testing period without a public
explanation of the new feature wouldn't hurt, either, so this may not be
so urgent.
A question (no time to check myself, sorry). If A has B as a sibling and
B has C, is C a sibling to A?
I take it that with sibling you mean that A deep-depends on B. I'd say
there is some room for interpretation or at least for supported
features. Of course, if B doesn't work without C (including its private
functions) then A fails if C's functions aren't also pulled in.
However, it's not clear whether this kind of transitive structure must
be supported. The deep dependence presupposes that A's author has
detailed knowledge about the existence of various functions. So IMO it
wouldn't be too much to ask of A's author to explicitly deep-depend on B
as well as C, without relying on some automatic recursion.
cheers,
sven