I posted the second appaweek project last week, based on the wxpywf framework from the wftk, as you know. And this week I've started mulling over app #3, and since I'd upgraded from Python 2.1 to 2.4, my old (ancient) copy of the McMillan installer was way outdated. Turns out that McMillan disappeared from the Net in about 2004, but some enterprising souls (headed by a guy in Puerto Rico, no less, at UPR!) have taken up the gauntlet and are continuing development under the name PyInstaller.
So that was good, but when I got down to business compiling the little filemonitor work-in-progress, I found that the wx libraries have now grown in size, with the result that the (already somewhat heavy) 2MB size of a simple compiled wx app has now become 5MB! Wow! (Of course, that includes the runtime and everything, but still...)
I don't want that kind of stuff bogging down my server, and already there has been respectable traffic around the appaweek projects. But there is an awful lot of specialized code involved in this venture: wx itself, of course, and the wftk's xmlapi and repmgr libraries, their Python wrappers, and the wftk and wxpywf OO wrappers around those. That's a lot of stuff to make people install, especially on Windows when they may simply have to install Python to start with! Which is why I wanted to do the compilation thing in the first place, of course.
So here's what I thought to do -- and this is what wxpywf was always intended to do: I brought the PyPop app up to date so that it displays the XML-defined UI just fine. And it would then be possible to do dynamic importation of a module to complete the application; PyPop already contains Python and all the libraries necessary to run things, so that would work fine. And yes, the UI for the filetagger app (app #2) displayed fine, although it naturally didn't do anything except display.
But then it occurred to me: Wouldn't it be nice if wxpywf could look at the XML definition of the UI and go ahead and build the CLI definition? And then I realized that if PyPop could (1) interpret the command line and put the results into the context, (2) load the data file and do the necessary Python indexing of it, and (3) build a Python CLI on the fly and link it to the frame, then, then...
Then the entire app would be in one XML file!
And a little bitty one, too, a whole app in about 20KB. That's a quick download! And then:
If the download of the app were managed through PyPop then we'd really have a Swiss Army Knife for software! And of course, more serious Python requirements could always import a Python file for better clarity, leaving the main application to define the CLI glue holding it all together.
Then envision this: imagine an application repository, and imagine the PyPop tool as a custom-thick-client "browser" of sorts. The local PyPop installation would manage common dialogs and applications in a versioned repository, and could check for updates every time you ran an app (or on a schedule). You could design your own UIs and submit them as project requests, and have a programmer fill in the hard parts. Every app built on this framework already knows about data management from the repmgr and about workflow from the wftk, it has logging and macro capabilities built in, and it runs Python. It could run Perl if you wanted to install it -- Perl's easy to embed in Python.
You'd know where all your little apps were, and you could trade them through the central repository or you could set them up for download yourself.
That would be pretty neat. Pretty neat indeed!
