On Thu, 17 Jan 2019, Sven Schreiber wrote:
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
>>> added to A's public list and its private functions to A's private
>>> 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
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.
Yes, I had in mind such a testing period before publicizing the
> 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 haven't had time to make the change yet, but it now seems to me that
"sibling" is the wrong word, since siblinghood is inherently mutual
(also transitive) and I don't have that in mind here. I'm now thinking
of "host" (or perhaps "server"). If package A specifies B as
(let's say) that gives A access to B's private functions, but not vice
I haven't even thought about multiple layers of hosting, but as things
stand the answer to the question above is No.