[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]
st: ado uninstall behavior
On 12 June 2003 Bill Gould wrote:
What is happening, case 3I 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.
Same scenario, but this time, the originally package A contained
You have seen packages like this: the author says "install this
and you will get two things, A and B."
Later, A is updated. Just to make things interesting, let's pretend
that A is updated not by the originally author, but by someone else.
not necessary, but it makes the story more interesting. Anyway, in
the new A
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
The old A has in it B.ado and B.hlp.
That's useful because, had Stata really removed the old A, you would
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
Stata could, in case 1, go ahead and remove the old A directory entry
in fact, serves no purpose. Case 1 is the most common case, to boot.
sounds better to me, but it bothers me a little that Stata's behavior
a little unpredictable beforehand. Do you need to uninstall the old
the improvement, only if it is still there and you know you don't want
Another altnernative would be to recognize that case 3 rarely happens
authors do a good job constructing packages, should never occur. You
remember that we wrote -net install- *BEFORE* we knew how users would
Anyway, case 3 is rare, so let's forget it, and change -replace- to
- -uninstall-, so the command would work just as David expects.
I suggest that we leave the decision up to Kit Baum <email@example.com>.
better than any of us how packages look and so can better evaluate the
frequency of case 3.
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.
SSC archive maintainer
* For searches and help try: