0

Under what conditions can a python script be considered portable given the following assumptions:

  • The script will be developed on one host (e.g., a CentOS or Ubuntu linux distro)
  • The script will be brought to another destination host (e.g., CentOS/Ubuntu)
  • It is not permissible on the destination host to use pip or any other mechanism to cause updates to occur (e.g., the server is in a clean room with no internet access and IT policy forbids updating)
  • It is not permissible to bring the dependencies to the destination host (e.g., via programs such as PyInstaller, cx_freeze, py2exe, or py2app: see relevant post)

Perhaps the solution is that a portable Python program is a program with no module dependencies and if the destination Python program version is also compatible. But, (1) I don't know if having no module dependencies is something that a Python script developer can live with; and, (2) I don't know what Python program version compatibility would actually mean (e.g., is any Python 2 script of any minor/patch version compatible with any other Python 2 script version)? Also, I assume that actually some modules are "core" modules that are always present across Python installations. Is this true? And, can incompatibilities arise if core modules or other modules that are deemed to always be present across Python installations have different version numbers. Can module version differences render a script non-portable?

The question is: is there any way via scripting to analyze a Python script to determine that it is portable, given the above constraints? Lacking that, is there any way via human inspection to make the same determination?

Community
  • 1
  • 1
Steve Amerige
  • 1,309
  • 1
  • 12
  • 28
  • 1
    The only way I can imagine is to build a test environment accessible to the developper team that is an exact copy of the production one. That means exactly same Python version and same additional modules if any (including knowing if they have been installed through the distro modules or directly as python sources). – Serge Ballesta May 17 '17 at 09:00
  • @SergeBallesta And, that would be difficult for software that is delivered to unknown customers that have "clean room" requirements where we are forbidden to re-distribute modules (for legal reasons). Thanks for your feedback. – Steve Amerige May 17 '17 at 09:08

1 Answers1

1

There are 2 possible ways (AFAIK) to develop scripts that have to be later run in closed production environment:

  • if you have full knowledge of the exact production environment, set up a test environment that is a clone of the production one. It makes sense for developpement teams that have no access to the production system but only develop for a specific platform.
  • if you want to be able to distribute your module to potentially unknown customers, you apply a reversed logic: you list all the requirements for your script and let the admin team control whether they meet them.

The latter way is more complex in a subtle way: as you normally want your script to be portable across most possible versions, you have to build (and automate) a testing platform for the different versions you declare to support.

In theory, it is possible to know in advance where a script will be portable: if it never comes close to any corner case, only use standard Python modules and only features that has not changed for many versions, it is likely to be portable across all those versions. But such requirements are hard to meet and even harder to control, so testing against different versions is the only foolproof way to make sure that a script will actually be portable.

Serge Ballesta
  • 143,923
  • 11
  • 122
  • 252