Re: st: Re: Listing user-written ado files called by program

[Phil Schumm <pschumm@uchicago.edu>]

At 01:27 AM 9/7/2011, Partho Sarkar wrote:
> Like most Stata users, I have accumulated a number of user-written programs (mostly downloaded from the SSC server, but also some other sources).  In a program I have written, I implicitly use some of these user-written programs via commands (e.g., rtfutil, listtab etc.).  I have to share this program with other colleagues/clients, who obviously will not have these downloaded programs.  So I would like to include a note with my program listing all the user-written programs which my program uses.  Since there are many of these, in several of my sub-routines spread over do files, it would be quite tedious to manually track them down one-by-one.  Any suggestions?


The ideal situation would be to have a way to track these dependencies (including specific versions) programmatically.  For example, if you write a command called -foo- that depends on version X of -foobar- and version Y of -foobaz-, then you should be able to indicate this somewhere (e.g., in your package file), and the install command (e.g., -net install- or -ssc install-) should comply by installing those dependencies automatically, or at least issuing a warning if they are not already installed.  Similarly, it would be nice if there were something like a "require" command that you could use in a do-file to check for a set of dependencies (including specific versions).

I have never spoken with the Stata cognoscenti about this -- they may have some interesting things to say.  Certainly, this type of dependency handling is more important in environments where people are frequently writing programs that plug into or extend other programs, or where they are making a lot of use of shared libraries.  There's no reason you couldn't do this in Stata/Mata, of course; Ben Jann's moremata package is an excellent example.  However, the amount of this that goes on is certainly much less than for certain other languages, and one could perhaps make an argument that for this reason, the added complexity isn't worth it.

In addition, while implementing this type of thing may sound simple, there are lots of potential complexities to consider.  For example, simply having certain dependencies installed on your machine doesn't automatically guarantee that these will be picked up in a given context -- your ado-path might change, or another ado-file with the same name (e.g., a different version of the same command) might supersede it.  Also, people may have legitimate reasons to have multiple versions of a command installed, if, say, when using -foo- you need an older version of -foobar-, but when using -foobar- by itself you want to use the most recent version.

Note that there are two things you can do immediately on your own to address this issue.  First, WRT dependencies in do-files (or ado-files that you write for use with a single project only), you can install them into an ado directory at the root of the project, and then version them along with the rest of your project code.  Since the current working directory (e.g., ".") is near the top of your path by default (only Stata's official directories are above it), any project-specific ado-files will always be picked up and used by default, regardless of where you might move your project (as long as you move your project intact, and execute your do-files from the project root).  Second, WRT dependencies for an ado-file you intend for more general use or to distribute to others, there is no substitute for writing tests.  You can then distribute these tests along with the ado-file (e.g., they can be included as part of your package), and provide users with instructions for running!
  the tests in your help file.  This doesn't ensure that the user has exactly the same environment as you used for development, but it does insure that your command(s) work as intended (which is, after all, the ultimate goal).


-- Phil


*
*   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/