Statalist


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: st: uninstall ado package


From   "Sergiy Radyakin" <serjradyakin@gmail.com>
To   statalist@hsphsun2.harvard.edu
Subject   Re: st: uninstall ado package
Date   Mon, 20 Oct 2008 16:13:57 -0400

Thank you Ben,

Stata Corp insists (and for a good reason) that authors of Stata
modules not to modify/override the modules shipped with Stata. Writing
my own -mynet-/-myado- leaves the same problem of special treatment (~
"don't forget that you have to uninstall foobar.ado with -myado
uninstall foobar- and not with -ado uninstall foobar- like any other
package").  I see no elegant solution here.

As I say, things are a bit more difficult than I describe here: the
package includes dependencies, which must be installed and configured
(imagine LaTeX being installed for your convenience, when you -net
install est2tex-). The names are irrelevant as long as there is a
convention on how they are to be formed. E.g. there were files with
special meaning in DOS: autoexec.bat and config.sys. It was just a
matter of convention, how they were named, but the OS new not only
where to find them, but also WHEN to look for them, and how to use
their content. The language of the Stata packages contains commands
like -d- for "description", or -f- for "file". I would want to see -i-
and -u- to be added there (both optional of course) with a command
line after each. And first one to be executed (by -net-, -ado-, and
all the other standard module-installing commands) after the package
is installed and second before it is uninstalled. This will handle
most of the difficult situations that I can imagine. Note that -net-
is a built-in command and thus can be modified by Stata, Corp only.

Another request to Stata Corp is to issue -program drop foobar- before
updating -foobar-. In case when -foobar- makes use of plugins, the
respective DLL is attached to the Stata process after the first call
and remains active ("opened", "attached") throughout the session (or
until dropped). The file may not be overwritten when it's in use and
hence programs using plugins may not be updated unless they are
dropped from the memory. Same applies to: -net install foobar,
replace-. It must detach foobar's DLLs before attempting to replace
them with newer versions. The workaround to this is to make ProgA to
call ProgB and drop ProgB after use. If progB uses plugins, progA will
make sure they are detached. Things are very difficult when there are
multiple Stata's running. (No attemp is made to synchronize the
updates between them).

Best,
   Sergiy




On Mon, Oct 20, 2008 at 3:31 PM, Ben Jann <ben.jann@gmail.com> wrote:
> I don't think that -ado- or -net- support anything like this. The only
> possibility (other than StataCorp changing -ado- and -net-) is to
> provide your own versions of -ado- and -net- such as
>
> prog mynet
>    gettoken subcmd 0 : 0
>    net `subcmd' `0'
>    if `"`subcmd'"'==substr("install",1,max(3,strlen(`"`subcmd'"'))) {
>        gettoken pkgname : 0
>        capture `pkgname'_on.ado
>    }
> end
>
> The program for -ado- would be slightly more complicated because the
> input can also be a package id. There will also be other details to
> take care of such as the -from()- option in ado.
>
> An issue is that -net- and -ado- are totally silent (i.e. they do not
> return any results) which makes it difficult to deal with them.
>
> Maybe a look at the code of -adolist- will be helpful (-ssc d adolist-).
>
> ben
>
> On Mon, Oct 20, 2008 at 8:37 PM, Sergiy Radyakin <serjradyakin@gmail.com> wrote:
>> Dear All,
>>
>> I have a command that creates some files during it's work, which in
>> their nature are neither temporary, nor permanent. (They exist more
>> than one session). They are created when the program is first launched
>> and changed occasionally after. An example may be a config file, which
>> determines the mode of use of the command (in reality things are more
>> complicated, a dummy config file could be simply supplied with the
>> package). I don't want to leave a mess on the user's computer and when
>> [s]he uninstalls the package with -ado uninstall foobar- I want to
>> clean up and remove all of these `temporary' files.
>>
>> Q: is there any way how I can provide an uninstall routine, that will
>> be called by Stata when the user issues -ado uninstall foobar- ? (I
>> prefer to avoid instructing "Don't forget that you can't remove this
>> package like any other package and must first call -foobar_uninst- and
>> then -ado uninstall foobar-).
>>
>> Earlier I asked about the possibility of receiving control immediately
>> after the package is installed (e.g. to add a command to the menu).
>> This request is symmetric, but with regard to uninstallation.
>>
>> Ideally, I would want to include into the package two files, e.g
>> foobar_on.ado and foobar_off.ado and have Stata's -ado- execute the
>> first after -foobar- is installed and the second before it is
>> uninstalled.
>>
>> Thank you,
>>   Sergiy Radyakin
>> *
>> *   For searches and help try:
>> *   http://www.stata.com/help.cgi?search
>> *   http://www.stata.com/support/statalist/faq
>> *   http://www.ats.ucla.edu/stat/stata/
>>
> *
> *   For searches and help try:
> *   http://www.stata.com/help.cgi?search
> *   http://www.stata.com/support/statalist/faq
> *   http://www.ats.ucla.edu/stat/stata/
>
*
*   For searches and help try:
*   http://www.stata.com/help.cgi?search
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/



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