Stata The Stata listserver
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

Re: st: ado dir behavior bug?

From (William Gould, Stata)
Subject   Re: st: ado dir behavior bug?
Date   Thu, 12 Jun 2003 12:40:16 -0500

David Airey <> writes, 

> I had log2html installed previously. [...]  I typed,
>        . ssc install log2html, replace
> [...]  when I look in my ado dir by typing view ado dir, I _still_ have both
> versions of log2html. I have to manually remove the old version.  This
> happens for all ssc installs. I don't think this behavior is helpful or
> expected, because I asked it to be replaced when I typed "replace".
> I view this as a bug.

It's not a bug, Stata behaves this way to handle a particular (and unlikely)
case, although upon reconsideration, Stata could act more sophisticatedly.  I
will explain.  Nick Cox <> wrote, 

> No bug, I think, but a misunderstanding.  -ado dir- shows you a _history_ of
> what you have installed.  [...]

There is some truth to that.

There are three cases I want to lead you through.  Case 3 is the odd one
and the one that caused us to make -net install- and -ssc install- behave 
as they do.

What is happening, case 1

Say I install a package named A, using either -net install- or -ssc install-.
A, we will assume, was not previously installed:

        . ssc install A

Let's assume A provides three files:


Later, let us assume, package A is updated.  In the new package, the same two
files are provided.  Anyway, we reinstall, and specify option -replace-:

        . ssc install A, replace

If we were now to do a -ado dir-, it would appear as if we have two copies of
A installed.  Actually, we do not.  There is only one copy of A.ado and A.hlp;
they are just two directory entries.

Irritatingly, if we want to get rid of the old one, we have to manually -ado
uninstall- it.

What is happening, case 2

Same scenario as case 1, but this time, the original package A contains 
three files:


and the updated contains only two:


This time, after we reinstall, 

        . ssc install A, replace

there is still only one coyp of A.ado and A.hlp, but A_sub.ado is left around,
attached to the originally A directory entry.  As before, and irritatingly, if
we want to get rid of the old A, we must manually -ado uninstall- it.  This
time, when we do that, A_sub.ado is erased, as well.

What is happening, case 3

Same scenario, but this time, the originally package A contained


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


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 <>.  Kit nows
better than any of us how packages look and so can better evaluate the
frequency of case 3.

-- Bill
*   For searches and help try:

© Copyright 1996–2019 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index