"pkg unload" opinions please?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

"pkg unload" opinions please?

PhilipNienhuis
Hi,

In bug #57522 I've entered a bug report for "pkg unload". In short, "pkg
unload" does not take package dependencies into account (unlike "pkg load"
which does do the right thing). This bug manifests itself in two scenarios:
1. When unloading a depender package, its dependencies that were loaded
implicity when loading the depender remain loaded. I think this isn't very
harmful, but it isn't elegant either.
2. But when unloading package(s) that happen to be dependencies of other
loaded packages (dependers), those depender packages aren't unloaded as
well. pkg.m obediently just unloads the dependency and doesn't emit any
information, warning or error about the reverse dependencies. As a
consequence, those depender package's functionalities may silently get
crippled.

Now the question is: What do we want "pkg unload" to do in the second
scenario, where we want to unload just package "A" but some other loaded
package "B" depends on "A", whether we know that or not.

Mike came up with a few options, repeated below.
I'll shamelessly put my own preference here on top, but I'll keep most of my
motives for a next post:

Given the fact that "pkg load" has an (undocumented) "-nodeps" option:
(A0. Document the '-nodeps' option for "pkg load")
A1. Emit an error and do not unload "A" and "B"
A2. Only unload package "A" if "pkg unload" was called with a "-nodeps"
flag; document and implement it.

Other options:
B. silently unload both A and B
C. unload both A and B, warning message about B
D. unload A, keep B loaded (current behavior)
E. unload A, keep B loaded, warning message that B may not fully work now
F. unload A, interactive prompt the user what to do with B
G. interactive prompt the user what to do with both A and B

To make the story complete, here's why I think this issue should be
resolved.

(1) (Repeating myself) By accidentally or purposely unloading only a
dependency, functions in other loaded packages may silently fail. Dependency
packages have no info about their dependers so it is not easy for users to
be aware of reverse dependencies.
(2) Bugs #41298 and #41215 (about implementing a "pkg test" feature) have
been revived and patches for them can be tested. In order to "pkg test"
packages they must be loaded incl. all dependencies, and it would be elegant
if packages loaded in the course of a "pkg test" run could be gracefully
unloaded afterwards.

Opinions?

Thanks very much,

Philip



--
Sent from: https://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: "pkg unload" opinions please?

marco atzeri-2
  Am 03.01.2020 um 15:43 schrieb PhilipNienhuis:
> Hi,

Hi Philip,
my 2c

> Now the question is: What do we want "pkg unload" to do in the second
> scenario, where we want to unload just package "A" but some other loaded
> package "B" depends on "A", whether we know that or not.
>
> Mike came up with a few options, repeated below.
> I'll shamelessly put my own preference here on top, but I'll keep most of my
> motives for a next post:
>
> Given the fact that "pkg load" has an (undocumented) "-nodeps" option:
> (A0. Document the '-nodeps' option for "pkg load")
> A1. Emit an error and do not unload "A" and "B"
> A2. Only unload package "A" if "pkg unload" was called with a "-nodeps"
> flag; document and implement it.

A1 should be default
A2 can can be useful in some testing condition.

> Other options:
> B. silently unload both A and B

this should require a separate flag like "-withdepending"

> C. unload both A and B, warning message about B
> D. unload A, keep B loaded (current behavior)
> E. unload A, keep B loaded, warning message that B may not fully work now
> F. unload A, interactive prompt the user what to do with B
> G. interactive prompt the user what to do with both A and B
>
> To make the story complete, here's why I think this issue should be
> resolved.
>
> (1) (Repeating myself) By accidentally or purposely unloading only a
> dependency, functions in other loaded packages may silently fail. Dependency
> packages have no info about their dependers so it is not easy for users to
> be aware of reverse dependencies.
> (2) Bugs #41298 and #41215 (about implementing a "pkg test" feature) have
> been revived and patches for them can be tested. In order to "pkg test"
> packages they must be loaded incl. all dependencies, and it would be elegant
> if packages loaded in the course of a "pkg test" run could be gracefully
> unloaded afterwards.
>
> Opinions?

for testing purpose it will be nice to unload all packages
in one shot

>
> Thanks very much,
>
> Philip

Regards
Marco


Reply | Threaded
Open this post in threaded view
|

Re: "pkg unload" opinions please?

Rik-4
In reply to this post by PhilipNienhuis
On 01/03/2020 09:00 AM, [hidden email] wrote:
Subject:
"pkg unload" opinions please?
From:
PhilipNienhuis [hidden email]
Date:
01/03/2020 06:43 AM
To:
[hidden email]
List-Post:
[hidden email]
Content-Transfer-Encoding:
7bit
Precedence:
list
MIME-Version:
1.0
Message-ID:
[hidden email]
Content-Type:
text/plain; charset=us-ascii
Message:
3

Hi,

In bug #57522 I've entered a bug report for "pkg unload". In short, "pkg
unload" does not take package dependencies into account (unlike "pkg load"
which does do the right thing). This bug manifests itself in two scenarios:
1. When unloading a depender package, its dependencies that were loaded
implicity when loading the depender remain loaded. I think this isn't very
harmful, but it isn't elegant either.
2. But when unloading package(s) that happen to be dependencies of other
loaded packages (dependers), those depender packages aren't unloaded as
well. pkg.m obediently just unloads the dependency and doesn't emit any
information, warning or error about the reverse dependencies. As a
consequence, those depender package's functionalities may silently get
crippled.

Now the question is: What do we want "pkg unload" to do in the second
scenario, where we want to unload just package "A" but some other loaded
package "B" depends on "A", whether we know that or not.

Mike came up with a few options, repeated below.
I'll shamelessly put my own preference here on top, but I'll keep most of my
motives for a next post:

Given the fact that "pkg load" has an (undocumented) "-nodeps" option:
(A0. Document the '-nodeps' option for "pkg load")
A1. Emit an error and do not unload "A" and "B"
A2. Only unload package "A" if "pkg unload" was called with a "-nodeps"
flag; document and implement it.

Other options:
B. silently unload both A and B
C. unload both A and B, warning message about B
D. unload A, keep B loaded (current behavior)
E. unload A, keep B loaded, warning message that B may not fully work now
F. unload A, interactive prompt the user what to do with B
G. interactive prompt the user what to do with both A and B

To make the story complete, here's why I think this issue should be
resolved.

(1) (Repeating myself) By accidentally or purposely unloading only a
dependency, functions in other loaded packages may silently fail. Dependency
packages have no info about their dependers so it is not easy for users to
be aware of reverse dependencies.
(2) Bugs #41298 and #41215 (about implementing a "pkg test" feature) have
been revived and patches for them can be tested. In order to "pkg test"
packages they must be loaded incl. all dependencies, and it would be elegant
if packages loaded in the course of a "pkg test" run could be gracefully
unloaded afterwards.

Opinions?

I like your option A as well.  Next best in my opinion would be option E.

--Rik
Reply | Threaded
Open this post in threaded view
|

Re: "pkg unload" opinions please?

apjanke-floss
In reply to this post by marco atzeri-2


On 1/3/20 12:23 PM, Marco Atzeri wrote:

>  Am 03.01.2020 um 15:43 schrieb PhilipNienhuis:
>> Hi,
>
> Hi Philip,
> my 2c
>
>> Now the question is: What do we want "pkg unload" to do in the second
>> scenario, where we want to unload just package "A" but some other loaded
>> package "B" depends on "A", whether we know that or not.
>>
>> Mike came up with a few options, repeated below.
>> I'll shamelessly put my own preference here on top, but I'll keep most
>> of my
>> motives for a next post:
>>
>> Given the fact that "pkg load" has an (undocumented) "-nodeps" option:
>> (A0. Document the '-nodeps' option for "pkg load")
>> A1. Emit an error and do not unload "A" and "B"
>> A2. Only unload package "A" if "pkg unload" was called with a "-nodeps"
>> flag; document and implement it.
>
> A1 should be default
> A2 can can be useful in some testing condition.

I agree.

>> Other options:
>> B. silently unload both A and B
>
> this should require a separate flag like "-withdepending"

Also agreed.

Cheers,
Andrew

Reply | Threaded
Open this post in threaded view
|

Re: "pkg unload" opinions please?

Mike Miller-4
In reply to this post by PhilipNienhuis
On Fri, Jan 03, 2020 at 08:43:26 -0600, PhilipNienhuis wrote:
> Given the fact that "pkg load" has an (undocumented) "-nodeps" option:
> (A0. Document the '-nodeps' option for "pkg load")
> A1. Emit an error and do not unload "A" and "B"
> A2. Only unload package "A" if "pkg unload" was called with a "-nodeps"
> flag; document and implement it.

I've already weighed in on the bug report, but I agree with this choice
as well.

> (2) Bugs #41298 and #41215 (about implementing a "pkg test" feature) have
> been revived and patches for them can be tested. In order to "pkg test"
> packages they must be loaded incl. all dependencies, and it would be elegant
> if packages loaded in the course of a "pkg test" run could be gracefully
> unloaded afterwards.

I've commented on #41215 that I don't think you need any explicit
unloading logic to complete this feature.

For full clarity, I think "pkg unload" and any logic or dependency
checks we add to it are purely for user convenience. Code that
temporarily loads and unloads packages ideally only needs to save the
path before and restore it after.

--
mike

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: "pkg unload" opinions please?

PhilipNienhuis
In reply to this post by PhilipNienhuis
PhilipNienhuis wrote

>
> <snip>
> Now the question is: What do we want "pkg unload" to do in the second
> scenario, where we want to unload just package "A" but some other loaded
> package "B" depends on "A", whether we know that or not.
>
> Mike came up with a few options, repeated below.
> <snip>
> (A0. Document the '-nodeps' option for "pkg load")
> A1. Emit an error and do not unload "A" and "B"
> A2. Only unload package "A" if "pkg unload" was called with a "-nodeps"
> flag; document and implement it.
>
> Other options:
> B. silently unload both A and B
> C. unload both A and B, warning message about B
> D. unload A, keep B loaded (current behavior)
> E. unload A, keep B loaded, warning message that B may not fully work now
> F. unload A, interactive prompt the user what to do with B
> G. interactive prompt the user what to do with both A and B
> <snip>
> Opinions?

Thanks for your opinions.
Yesterday I've entered a cset in the bug report (bug #57522) along the lines
of option "A" which -based on the limited nr. of responses- seemed the most
popular one.

Based on the experience with fixing this I can say that IMO it isn't too
hard to implement any of the other options, maybe with new option flags.
Although automatically unloading depender packages plus packages depending
on those dependers, etc., may yield some surprises for unwary users.

Philip




--
Sent from: https://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html