st: ado uninstall behavior

[Kit Baum <baum@bc.edu>]

On 12 June 2003 Bill Gould wrote:

...

> What is happening, case 3
> - -------------------------
>
> Same scenario, but this time, the originally package A contained
>
>         A.ado
>         A.hlp
>         B.ado
>         B.hlp
>
> You have seen packages like this:  the author says "install this 
> package,
> and you will get two things, A and B."
>
> Later, A is updated.  Just to make things interesting, let's pretend 
> this time
> that A is updated not by the originally author, but by someone else.  
> That is
> not necessary, but it makes the story more interesting.  Anyway, in 
> the new A
> included are
>
>         A.ado
>         A.hlp
>
> B is not included in the "updated" package because the updating author
> cared nothing about B, or had no updates to offer.
>
> So now when you reinstall A,
>
>         . ssc install A, replace
>
> You still have two A's installed.  A.ado and A.hlp are part of the new 
> A.
> The old A has in it B.ado and B.hlp.
>
> That's useful because, had Stata really removed the old A, you would 
> have
> lost B.ado and B.hlp, and you might still want that.  If you do not,
> you can manually uninstall the old A.
>
>
> What could be better
> - --------------------
>
> Stata cannot tell case 2 from case 3, but case 1 is certainly 
> distinguishable.
> Stata could, in case 1, go ahead and remove the old A directory entry 
> which,
> in fact, serves no purpose.  Case 1 is the most common case, to boot.  
> That
> sounds better to me, but it bothers me a little that Stata's behavior 
> becomes
> a little unpredictable beforehand.  Do you need to uninstall the old 
> A?  With
> the improvement, only if it is still there and you know you don't want 
> it.
>
> Another altnernative would be to recognize that case 3 rarely happens 
> and, if
> authors do a good job constructing packages, should never occur.  You 
> must
> remember that we wrote -net install- *BEFORE* we knew how users would 
> use it.
> Anyway, case 3 is rare, so let's forget it, and change -replace- to 
> mean
> - -uninstall-, so the command would work just as David expects.
>
> I suggest that we leave the decision up to Kit Baum <baum@bc.edu>.  
> Kit nows
> better than any of us how packages look and so can better evaluate the
> frequency of case 3.
I think case 3 is indeed rather rare. I don't think if it does appear 
it indicates that authors are building packages sloppily; case 3 arises 
when, e.g., someone figures out that they can just call one of Nick's 
routines rather than inline coding it. At some later date, they may no 
longer need that routine, or decide that it is worth it to code the 
subset of the other file inline. So their revised package no longer 
calls for B. Admittedly if 'replace' meant 'bring up to date, and 
remove all no-longer-current code' you would lose B; but that is easy 
enough to rectify.

Another situation in which this may happen is where the author used 
private code B, which is now integrated into Stata. Then B is truly 
obsolete, in the sense that everyone should prefer to use the supported 
version rather than the privately authored version (e.g. -levels-).

So I see no problem in revising -net install, replace- and -ssc 
install, replace- to do a cleanup job when executed.

Thanks
Kit Baum
SSC archive maintainer

*
*   For searches and help try:
*   http://www.stata.com/support/faqs/res/findit.html
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/