Transitioning a Python Library on a Shared Network Drive to eggs/setuptools
In the past I've managed a shared library of Python packages by using distutils to install them in secondary Library and Scripts directories on a shared network drive. This worked fine, even in our multi-platform environment. With advent of eggs, however, the secondary Library directory must be a formal "Site Directory" and not just on sys.path. The extra delay caused by the layer of network has caused simply getting --help for a simple script to take almost three seconds when it previously only took a tenth of a second. Some scripts that use many packages installed as eggs on the network drive can take as many as 8 seconds just to display the help message. I would like to install architecture independent Python packages in a single shared location so that everyone using that location is automatically upgraded. The in-house packages are modified about five times a day on average. I would like to take advantage of setuptools versioning (thus using the pkg_resources mechanisms) so deprecated portions of the system can be kept intact in some frozen state of development without having to include the version number in the package name explicitly (i.e. mymod, mymod2, .., mymod42). What is the recommended way of using eggs in such an environment? Your thoughts and advice are appreciated, Alex
participants (1)
-
Alexander Michael