Supporting multiple Python module versions (with the same version of Python)

Question

I looked around but cannot find a clear answer to my question.

I have a very legitimate need for supporting N-versions of the same Python module.

If they are stored in the same same package/directory, they would have to be uniquely named, like in the following example:

      .../some/package/my_module_1.0.py
      .../some/package/my_module_1.1.py
      .../some/package/my_module_2.0.py
              -- etc. --

And each would, in turn, store its version number via the "version" attribute.

The consuming program then imports the correct version that it needs (e.g.: import my_module_1.1).

Is this the optimal (and most pythonic) way to accomplish this multi-module version need?

Thank you!

Estheresthesia

It would be good if you just made the module compatible with both versions. – Seleucia

Thanks. I'm not sure I understand what you mean. Can you elaborate? Also, remember that there may be many versions, not just two (there's a reason -- it has to do with ETL pipeline stuff, but I won't bore everyone). :) – Estheresthesia

I can't say that it is necessarily possible to do this because I can't see the code, but if you wrote my_module_*, you might be able to keep the syntax compatible with more than one version. For example, except Exception, e: is valid syntax in Python2, but not in Python3, so you should use except Exception as e: because it is valid in both versions. – Seleucia

Oh, dear. No, I don't mean a module that needs work across different python interpreters (like Python 2 and 3). I mean simply multiple versions of the same module (say, in just Python3 for simplicity). – Estheresthesia

Does the consuming program know which version it needs? In that case it simply picks the right import by a sequence of if:else: statements. You may also want to look into sys.__modules__, which contains a dictionary of imported modules keyed by name, usually the file name. You might be able to hide the versioning issue by importing the right module and always storing it under the same key, regardless of what its actual file name is. – Darill

Try googling for supporting multiple rest api versions for django/flask - this sounds like a similar problem to yours. – Avner

Yes the program will receive a configuration object derived using ConfigParser and an ini file (so it will know the exact version). And it will need to use that exact version supplied (or manually raise an exception if not available). It cannot do something something like "use the latest version; then the next latest version if that's not available" and so on. Really though, I was looking for the best practice directory structure. Perhaps the one I wrote in the question will suffice. But open to ideas. I will look at sys._modules__. Thanks. – Estheresthesia

Answer 1

I did some googling for "flask support multiple API versions", and found this stackoverflow post to be pretty handy.

In short, the only real difference suggested in that post vs what you've provided is that they use subdirs for each version, and each version is a module itself.

If you're able/allowed to share common functions/objects between versions, this structure might make maintaining/managing your module easier.

some_package
+--- my_module/
     +--- v1_0/
          +--- __init__.py
          +--- some_file.py
     +--- v2_0/
          +--- __init__.py
          +--- some_file.py
     +--- __init__.py
     +--- common_stuff.py

But if you cannot share things between versions, then your current idea works just fine, and is simpler.

And then you could import it like this:

import my_module.vX_Y as my_module

Avner

Thanks @willnx. I saw your note above. Let me give this some thought/time. If I can't find something better (not that your answer is bad) then I'll mark it as an answer. I already up-voted though. =:). Thank you, – Estheresthesia