`reprun`: Handle `clear all` dropping programs

[bbdaniels]

Ensure that reprun doesn't break when the target file calls clear all, clear *, or equivalent. This may be solved by making sure the command is fully installed by the user but need to check. See 932ec9764d886bfb1752bf6e09dd955f9c5ec1c5 for a dicey implementation in the prior version -- Hopefully nothing like that will be necessary. (worldbank/ietoolkit@932ec97#diff-36d36e7ffbaaeb3a44fc03eb77b0e9f5347f491c7fcedb2a3f732315323ecb60)

[kbjarkefur]

clear all was no issue when the command was installed. I have included an test example E that tests this in 24bd552.

One important for our test file to handle this is to not load the command using qui do "${ado_fldr}/reprun.ado". As that only loads the command in memory. This is not the best simulation of the user experience, as a user will have the command installed. Therefore, I have updated the test file to net install the package from the clone. The adodown workflow makes this easy as the .pkg file is kept up to date. See here:

https://github.com/dime-worldbank/repkit/blob/c3a12dc2e0293813f75c4ce33e4768c16510f2bf/src/tests/reprun/reprun.do#L22-L26

Now when we have repado I think all our test files should use this as net install repkit, from("${src_fldr}") replace creates a more relaistic test environment than qui do "${ado_fldr}/reprun.ado".

This clear all case is one example. But another example is that when we use qui do "${ado_fldr}/reprun.ado" all sub-commands, such as reprun_recurse is also made availible as the ado file behaves as an ado when executed with do.

@bbdaniels , can you test that example E:

• Really replictes the clear all case you previously had an issue with
• Now runs without error for you as well

[kbjarkefur]

However, I created a test example for a project that sets the PLUS path. This works without needing to either install repkit in that project's ado-folder or moving the reprun_dataline ado folder there.

Can you test if example F works for you here (note it is a different branch): https://github.com/dime-worldbank/repkit/blob/9867f981ec21075390204827981daa888f32c049/src/tests/reprun/reprun.do

The weird thing is that the run1 and run2 do-files that has reprun_dateline in them works. Even though the PLUS folder has been set to a folder where that command does not exist. What is even weirder is that if I add which reprun_dataline immedeatly after a line in one of those do-files where reprun_dateline was used, I get the error command reprune_dataline not found as either built-in or ado-file.

I do not have more time to investigate today or this week. @bbdaniels , as a first step, can you also test that example F runs without error in this branch for you. Can you look if you see something that is strange or something that explains why this can run?

[bbdaniels]

When I changed the main.do file to use clear all it broke. I will try to fix it.

[bbdaniels]

This appears to be resolved.

[bbdaniels]

@kbjarkefur I cannot run the test files with clear all in most recent code. Re-opening this for testing....

.     * Example E - with clear all
.     cap mkdir "${wca}/output"

.     reprun "${wca}/main.do" using "${wca}/output" , debug

    Starting reprun. Creating the do-files for run 1 and run 2.
    Done creating the do-files for run 1 and run 2.
    Executing "main.do" for run 1.
    Done executing "main.do" for run 1.
    Executing "main.do" for run 2.
    Done executing "main.do" for run 2.
    Generating the report for comparing the two runs.
command write_and_print_output is unrecognized
r(199);

end of do-file

r(199);

[bbdaniels]

Strangely, this is resolved by restarting Stata. Perhaps there is something not fully reset if repado is run more than once? This may be an issue with that command instead....