Is it possible to upgrade a Python package on the fly?

Question

I maintain an in-house Python package which is used by some not-really-technical people in the company. Being that their needs (or rather, their wants) change on an almost-daily basis, I have to update the library pretty often, and I create new installers for them too often for their liking.

The lib provides a high-level access to a custom in-house database. At this point, I know that I could send the lib version along with the query request, and show the user a message with the result that they need to install an update.

However, being that these people seem to think that taking a few seconds to click on an .exe file and clicking through the "next" buttons on the installer takes too long, I'm being asked to see if there's a way to automatically update the library when they do the "import X" call.

I have never come across this kind of request, and I'm thinking that if this was possible that most popular libraries would offer this option. But I've been wrong before, and often. Has anyone successfully done this before?

Harbison

I've seen this done successfully in the past, for exactly the reasons your describe. It's not hard, but I can't think of an out of the box solution for Python modules. (+1) – Kall

I don't see why you couldn't download all the files, copy them into place and then call reload() on the module... But I really don't think it's a good idea. What if there's an update that breaks everything? People wouldn't be able to prevent their systems being broken by the auto-upgrade. If they need updates that fast, can't they work direct from a branch in the repo you're using instead of using an installer? Then they can sink whenever they like. Or they could be less lazy, of course. (^_^) – Cardiganshire

@Cartroo: I don't think breakage is an issue. After all, running an installer can break everything too. – Eppes

@John Y: Sure, but that way the breakage is to some extent under the control of the user. I happen to notice I've broken my system, I send a quick email telling people not to upgrade until the issue is fixed. With the auto-upgrade, however, the users are all frozen out of using the library until the issue is fixed, because any use of it will auto-upgrade to the broken version. Of course, one could imagine something like setting an environment variable to prevent the upgrade, but to me it's just an inherently risky approach when the gain is only a marginal amount of convenience. – Cardiganshire

@Zaphod STOP vandalizing your questions!! – Superimposed

Answer 1

I apologize if this is merely a comment.
But there are a few options available I think. And I have to agree with Cartroo, a reload() function might be sufficient.

There is a great article on this (Charming Python: Reloading on the fly) website. I am not completely sure if this is exactly what your looking for but the example in the article seems to match your needs pretty closely.

Let's paint a scenario for this article: Suppose you want to run a process on your local machine, but part of your program logic lives somewhere else. Specifically, let us assume that this program logic is updated from time to time, and when you run your process, you would like to use the most current program logic. There are a number of approaches to addressing the requirement just described; this article walks you through several of them.

Checkup

Answer 2

Have the "import X" call run a code in a wrapper library. The code the time of import would check the database for a new version of the library and download if it has changed. Then it can in turn import the downloaded library or import the existing library. There may be issues with this on frozen code so you might have to explicitly eval the new module.

Edit: This does not necessarily need to be done in another module. It could just be a function call.

Airborne