Continuing the discussion from Python3 switch and python package install:
Are there any updates on the automatic installation of Python packages required by extensions? The packages we’d like to use can be installed manually, but the user needs admin privileges.
@lassoan and @jcfr, do you know if automatic installation is likely to be available sometime soon? Thanks!
do you know if automatic installation is likely to be available sometime soon?
To put things in context, are these packages you would like to have available after the user install SlicerMorph extension ?
Yes, thanks. For example, we plan to provide sample scripts to manipulate our module’s data output and would like to use the Pandas package in the scripts. It would be very convenient if we could have this package automatically downloaded with our extension.
On mac (and probably linux) this works:
>>> import os
>>> os.system('PythonSlicer -m pip install pandas')
>>> import pandas
On windows, this process pops up the access control permission dialog:
os.system('powershell.exe Start-Process cmd.exe -Verb runAs')
And then in the shell I could run this:
"c:\Program Files\Slicer 4.11.0-2019-06-02\bin\PythonSlicer.exe" -m pip install pandas
We should be able to streamline this and integrate it with the extension install process.
We discussed this on the developer call the other day and were thinking we should start collecting this information along with guidelines about which python packages should work and which might cause trouble.
We plan to add a
slicer.util.pip command that launches pip as admin (displays UAC popup) on Windows.
We could also add some higher-level helper function that would ask user confirmation in a popup before installing anything, explain what version of what package will be installed, and could display errors, etc.
So both of these answers assume user have admin rights?
If Slicer is installed to a folder that requires admin rights then yes, currently you need admin rights to install Python packages. If this is a problem then there are many way to address this.
We can change Slicer install location to be in the user’s folder (e.g., AppData) instead of the shared “Program Files” folder. We could also allow users to choose the folder. This should be very easy (modification of a few lines).
We could try to make pip manage packages in two folders (core packages pre-installed with Slicer in “Program Files” and additional packages installed by extensions in user’s folder). We would do something unusual, so it may be hard to implement and maintain this solution.
We could install all extensions to the user’s folder. Probably we would need to copy core extensions from the Slicer core folder in Program Files on or before starting Slicer the first time. If would not be a very simple mechanism, but it could allow sharing a single Slicer installation to be used by multiple Python environments and it would be possible to reset the default environment (because it is stored in a read-only location).
I think modifying the windows installer would be a good place to start. I just tried installing with a normal user account, and once UAC pop ups, it asks me for an admin account password. Hitting the cancel button, cancels the whole installation process. Instead, the behavior should be asking whether they want to install to their user space or somewhere else where admin rights is not required.
The whole getting the updates through new preview installs is really challenging to coordinate in corporate networks…
It should be possible to ask if Slicer should be installed for all users or the current user.
If we put some work in the installer, it may be worth revisiting the use of NSIS and instead look at WIX.
This makes me think of what is done with virtualenv. That said, you are right it may be more cumbersome to implement
On windows and Linux, this is already the case. Extensions are installed in the user folder.
I’ve submitted a pull request to change the default install location to AppData (c:\Users<username>\AppData\Local) and turned off requirement for an admin account.
Installing in user-specific folder may be a good thing, because then installing random Python packages would not impact other users.
The only drawback I can think of is that after this change it will be a bit more work to create an installation tree shared between all users on that computer. However, it is not that difficult to do: you need to manually select All Users\AppData as installation folder and move the start menu shortcuts to All Users\Start menu. We can just add these instructions to the documentation.
Also, as an FYI, we are planning to work on the slicer.util.pip functionality and the automatic install of packages for extensions during the upcoming project week.
Would the same slicer installation be usable by other other user accounts if the default it c:\Users<username>? I thought those folders are specific to the user, unless explicitly allowed.
Perhaps you can let user manually choose a folder that they can write to (e.g., c:\Slicer-4.11) which then can be shared by other users of the same computer?
Visual Studio Code has a User Installer and a System Installer for download. I know this program does this to allow easier frequent updates using the user install.
VS Code provides both Windows user and system level setups. Installing the user setup does not require Administrator privileges as the location will be under your user Local AppData (LOCALAPPDATA) folder. User setup also provides a smoother background update experience.
The system setup requires elevation to Administrator privileges and will place the installation under Program Files.
Yes, everything is still doable (see my post above). However, we need to choose between which of these use cases we want to support by default:
- A. User (does not need to be administrator) installs Slicer and any extensions.
- B. Knowledgeable administrator sets up Slicer and all necessary extensions for all users on a shared computer.
Since use case A is much more common, I think we should make that easy for users, and let experts deal with the few required extra steps needed for a shared installation.
We could create two installers as @jamesobutler suggested above, but I am not sure if it is worth the extra effort (it would impact packaging and release download infrastructure, lead to more questions from users, etc.).
I’ve integrated the change, from tomorrow, Slicer-4.11 install will note require admin rights on Windows and Python packages can be installed as regular user.
Slicer install tree can be accessed as
%LOCALAPPDATA%\NA-MIC (usually it resolves to something like
Previous behavior (install to Program Files, require admin privileges) can be restored by adjusting
Slicer_CPACK_NSIS_INSTALL_REQUIRES_ADMIN_ACCOUNT variables when configuring Slicer build).
I went ahead and added a slicer.util.pip_install function because @ungi will give a Slicer tutorial at CARS conference next week where he needs to walk through participants installing Python packages, and typing
pip_install("tensorflow") in Slicer is much easier than locating Slicer’s Python, start a command terminal there, and type
PythonSlicer.exe -m pip install tensorflow. We can refine the syntax and add features later.