Conflicting Python Packages How can it be Resolved?

Question

So we went to implement something today, and discovered that there already is several applications relying on the old implementation of our inhouse python library. Called cis_py. Now all applications for our implementation currently sit in a folder called, bin. This is where cis_py currently resides.

Now we went to deploy one of our big python applications, which uses the new version of our inhouse library. We cannot simply overwrite the existing versions of it. Since this will cause all of the existing applications to break.

Basically i cannot update the existing applications, nor can i rewrite the new application. Now i was thinking of trying the following:

cis\cis_py\<python library files>

Then do a search and replace on the existing application and change the following:

cis_py.<some python file>

To

cis.cis_py.<some python file>

Unfortunately this results in several of the __init__.py files in the library breaking, due to the use of this:

from cis_py import rga
from cis_py import util

Today is implementation day, and it must go live today, since in a few hours we start receiving data automatically.

How and what can i possibly do? Everything must reside in a single folder called bin. Due to the automatic processing system. Is there some way i can possibly trick python?

Answer 1

Try import sys; sys.path.insert(0, "cis") as the very start of your main Python file.

Answer 2

Step one is to start telling people about this issue. Talk to your co-workers and boss and inform them of the problem you discovered, since it is possible that the go-live will have to be called off or postponed while a solution is worked on. Changes will have to be made somewhere, and it would be good (and may be required) to perform additional testing to verify those changes don't break anything.

Without knowing much about how your system is being run, one guess is that maybe you can run the new version under a modified environment that directs it at the new version of the library?

Answer 3

Add a version to the name: cis_py2. You may have to make changes in the class, but nothing that can't be done with a quick script (don't run this without testing it first):

sed 's/cis_py/cis_py2/g' `find -name '.py$'`

This assumes that cis_py is only the module name and nothing else has the name.

Answer 4

It looks like Alex Martelli's solution solved the emergency for you. Here's another solution, one I think better for the long term.

In source files, replace the line

import cis_py

with the line

import cis.cis_py as cis_py

That way, when later code says from cis_py import foo, it will work.

This is less "magical", because each source file will include this changed import line, so someone studying a source file will understand the true source of the cis_py module (without needing to also study the main Python source file).