[Gretl-devel] Belated response to Sven on function packages

Before I try responding to the list of small bugs that has appeared on gretl-users, I'd like to come back on some points that Sven raised earlier, regarding function packages. First of all, py4gretl is very cool! Thanks for making this available. One request: I think it would be very helpful if you could put up a few examples of use of the py4gretl functions. (I have this is mind, though it's not yet implemented: allow for a .gfn file to contain a complete, runnable sample script.) Now, on a few design issues. * Should we have a standard File Open dialog that allows you to open .gfn files from anywhere in the filesystem? On reflection, No, that would likely be confusing for most users. Unlike regular .inp files, .gfn files are supposed to be special. There are two authorized locations for such files: @gretldir/functions and @userdir/functions. If you want to be able to open such a file, then put it, copy it, or symlink it into one of those locations. * Version numbers embedded in gfn filenames. I started along the road of trying to accommodate this, but I now think that was a mistake. One symptom is the issue Sven mentioned, that if you upload a new version of a package to the server, the old one will still hang around, if it has a different filename, and you can't delete the old one. What's supposed to happen is that when you post an update the old file is automatically overwritten, which will happen if they have the same name. Also, version numbers in the filename are redundant from a user's point of view (the version is recorded inside the file), and they take up space unneccessarily in the function package dialog window. [To make the redundancy point more persuasive, I've now modified the dialog so that it shows the version number beside the name.] I can see that from the point of view of a function package developer, it's convenient to have versioned filenames. My suggestion would be: keep the files with the versioned names in a separate directory, and symlink the one you want to use currently into @userdir/functions @userdir/functions/foo.gfn -> /other/place/foo-1.28.3a.gfn If this sounds reasonable, I can rename the py4gretl files on the server accordingly. * Which functions appear as available for packaging in gretl? I haven't had time to check this fully, but here's what's _supposed_ to happen when you load function package P: - P's public interface (which should have the same name as the package) will _not_ appear as packageable. That's intentional: it's already packaged and shouldn't appear as the public interface of any other package. - If there's at least one "free" function available for packaging, then any helper functions inside P should be available: helper function are supposed to be reusable. - How do you make "free" functions available? For example, put them into an .inp file and run it. - If you really want to "cannibalize" a package -- that is, steal its public interface and use it to make another package, then you'll have to do some copying and pasting. Copy the code out of the code-editing window in the function packager and paste it into an .inp file. Re-start gretl; load and run the .inp file. Allin.