7

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!

NYCeyes
  • 5,215
  • 6
  • 57
  • 64
  • It would be good if you just made the module compatible with both versions. – zondo Mar 15 '16 at 01:18
  • 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). :) – NYCeyes Mar 15 '16 at 01:22
  • 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. – zondo Mar 15 '16 at 01:24
  • 1
    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). – NYCeyes Mar 15 '16 at 01:28
  • 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. – Paul Cornelius Mar 15 '16 at 01:32
  • Try googling for supporting multiple rest api versions for django/flask - this sounds like a similar problem to yours. – willnx Mar 15 '16 at 01:33
  • 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. – NYCeyes Mar 15 '16 at 01:41

1 Answers1

3

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
Community
  • 1
  • 1
willnx
  • 1,253
  • 1
  • 8
  • 14
  • 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, – NYCeyes Mar 15 '16 at 02:10