Am 17.02.2018 um 20:49 schrieb Allin Cottrell: > On Sat, 17 Feb 2018, Sven Schreiber wrote:
>> I'd actually go so far as to say that saving the functions to a >> session file in the first place is already a mistake. >> It has been explained (to me and others) that the session concept is a >> GUI thing. I don't see why contributed functions need to be saved in >> there. > Well, maybe you're right, but here's the sort of thing you may be > missing. Suppose I save an SVAR result "as an icon" then save my > session. I (or perhaps someone else) later opens the saved session file, > and double-clicks on the icon. This should result in a call to the SVAR > bundle-printer function. Hm, I see. > One thing is clear: _if_ we're going to save loaded functions in the > session file, we have to mark the ones that belong to specific packages > as owned by those packages so we don't get false-positive conflicts. Right. That sounded very complicated, but maybe it's not, given that in functions.xml (inside the session file) the functions already appear in context with their owning packages. I'm wondering about different package versions, though. Say I have an old session file with embedded package foo.gfn version 0.1. In the meantime the package is at version 2.5. If I load the session and then do 'include foo.gfn', what is supposed to happen? Always load the latest available package version and replace the older function versions? (In memory I mean, not in the session file.) That would mean to tell users not to do 'include' if they want to rely on the function versions embedded in the session file. Or a switch could be added to 'include' that clarifies this. Like --keep-old or something. cheers, sven
