Problem with package updates
Some Canopy users are on networks which are disconnected from the internet, so are unable to acquire package installs or updates from the internet.
There are two main situations when a user will want to acquire and install packages, which would normally be done from the internet using the Canopy Package Manager or the "edm" ("enpkg" in Canopy v1) command-line utility.
- The standard Canopy installers include only the core scientific packages in the Enthought repository. Right after installation, any additional desired packages (e.g. popular packages such as Pytables, and H5py) can be installed from the repository. However users who are disconnected cannot do this.
The solution for Enthought subscribers (paid) is to download our full Canopy installer. These installers should contain nearly all Enthought (Canopy / EPD) packages as of the date the installers were built. Note that if Canopy was already installed, then you must also reset the Canopy User Python environment, or the new installer's packages will not be installed. See Updating the Canopy application and its Python packages.
- Many of the most widely used packages in Canopy, such as Pandas and Matplotlib, are under active development, so that new versions are released regularly; users will want to install these updates. Also new packages are regularly added to the repository, so that some may not yet have been added even to the Canopy Full installers.
Full Solution for package updates
The Enthought Deployment Server allows you to maintain a mirror of the Canopy / EPD repository, on the disconnected network, under the control of your sys admins. This server can also be used to host / serve your own internal packages to your organization.
[Does not include Canopy v2 & edm] Workaround for package updates -
First, get the necessary egg (pre-built package) files by one of two methods, either 1 or 2:
1. Usually easiest - if you also have a connected machine, running the same OS (and the same 32/64-bit Canopy version):
a) For all packages installed this way, their "egg" files will be cached in the LOCAL-REPO subdirectory of your Canopy User Python directory (you can find it by looking for "LOCAL-REPO" in the output of "enpkg --config"). Note that this directory does not contain any actual package installations, but rather is a file cache from which the packages can be installed. For example, there might be multiple versions of egg files for the same package, but only one of them would be currently installed. Or you could delete all these egg files, without affecting any installed packages, though we don't recommend it because it would mean that you'd need to re-download an egg file if you needed to re-install a package.
b) the "enpkg --log" command on the connected machine will show you a chronological log of all package installations, including dependencies. You can use this as a guide to which eggs you want to copy to the disconnected machine. If your connected and disconnected machines started with the same Canopy version installed, then "Rev 0" will already match on the two machines, and you'll just need to focus on installing the packages listed since Rev 0.
c) For more fine-grained tracking of the dependencies of a particular package, run this command on the connected machine:
python -m enstaller.tools.list_dependencies <package-name>
d) For most packages which Canopy User Python inherits from Canopy Core Python, either as part of the original Canopy installation, or as a result of subsequent Canopy application updates, their "egg" files will be cached in the LOCAL-REPO or EXTRA-REPO subdirectories of your Canopy Core Python directory. These directories can be located within a running Canopy User Python (either in the GUI application or in a terminal session), and looking in sys.path for several directories whose paths contain "/appdata/" followed by a version- and platform-specific directory such as to "canopy-220.127.116.1185.rh5-x86_64". As mentioned above in (a), these egg files are not the actual package installation, but are the source for subsequent installations. But unlike the LOCAL-REPO file in User, mentioned in (a), this set of egg files is static, limited to whatever was bundled with your original Canopy installation.
e) For a few large packages which Canopy User Python inherits from Canopy Core Python (MKL, Qt, shiboken, and PySide), there are no egg files to locate. If these packages have been updated as a result of a Canopy application update, and you wish to provide the update to a disconnected installation, you should first use enpkg to install the packages explicitly into the connected Canopy User Python, and then proceed as in (a).
or 2. Alternate method, if (1) is not possible:
a) Log in to the Enthought web site, then go to https://packages.enthought.com/ui/eggs/enthought/gpl/cp27
(for Python 2.7; substitute cp35 or cp36 for Python 3.5 and 3.6, respectively).
b) Download the desired egg file. Typically you'll want the latest version of each required package. Be sure to select the correct OS and 32/64-bit version. Note that dependencies are not explicitly specified, so you may need to repeat the process several times until all necessary eggs have been installed.
3. Then sneaker-net these egg files to a directory of your choice on your disconnected network, accessible to your disconnected Canopy installation.
4. From a command line where Canopy User Python is the default Python, for each egg file:
egginst --remove <package name>
egginst <path to egg file>
(the "--remove" step can be omitted only if you are certain that the package is not already installed.)
Updating the Canopy application
(For background on virtual environments, see this description.)
1. Uninstall the Canopy app as described in this article (since you are planning to re-install, do not do the 2nd part of that uninstallation procedure, unless you want a clean install).
2. Download the new version's installer, copy it to the disconnected machine, and install it. Unlike with EPD (where any new EPD install was always clean, so you then had to start over with installing and configuring all your add-on packages) this installation will leave your User virtual environment untouched. There is one exception, for core packages that are included in the installers:
Let's take numpy as an example. If your existing Canopy installation included numpy 1.6, and the new Canopy installer includes numpy 1.7, and you had never updated numpy in Package Manager or with enpkg, so that the User environment was inheriting numpy 1.6 from the System environment, then numpy 1.7 will, after your Canopy update, now be silently inherited by your User environment. We recognize that this is a mixed blessing, and are discussing the appropriate resolution. We would value your feedback to firstname.lastname@example.org .
Updating from behind a proxy
If you are not actually disconnected, but simply behind a proxy firewall, the solution is usually much simpler. Please see this article.
Enabling the GUI debugger and Data Import Tool
For commercial subscribers on disconnected machines who wish to use the Canopy GUI debugger and Data Import Tool, please contact us at email@example.com for manual activation credentials.
For group academic (not individual academic) subscribers on disconnected machines who wish to use the Canopy GUI debugger (the Data Import Tool is not covered), please contact us at firstname.lastname@example.org for manual activation credentials.