[FIXED] How can I open jupyter in a venv with a shortcut?

Issue

I installed Jupyter in a virtual environment on Windows 10 using the following Powershell commands:

virtualenv --python C:\Path\To\Python\python.exe venv-name
.\venv-name\Scripts\activate
pip install numpy matplotlib jupyter notebook pandas joblib scipy sympy
jupyter notebook

I have done absolutely nothing beyond this other than having Python and virtualenv on my computer. To get into Jupyter notebook, I run lines 2 and 4 of this in Powershell, which works just fine.

How can I achieve the same effect of opening Jupyter notebook using a Desktop/Taskbar shortcut?

I read the answers to this question, but both of the useful answers make use of conda and Anaconda, which I do not have, and do not really want to have as it seems like it should be unnecessary for this task.

Solution

Based on your description of how you open Jupyter Notebook from an interactive PowerShell session (lines 2 and 4), you'll need to make your shortcut file call powershell.exe, the Windows PowerShell CLI, with said statements.

Here's a PowerShell snippet that creates a shortcut file programmatically:

# Path to the shortcut file; adjust as needed.
$shortcutFile = "$env:USERPROFILE\Desktop\Jupyter Notebook.lnk"

# Create the shortcut file...
$shortcut = (New-Object -ComObject WScript.Shell).CreateShortcut($shortcutFile)

# ... and set its properties.

# Specify the target executable and its arguments.
$shortcut.TargetPath = 'powershell.exe' 
$shortcut.Arguments =
  '-NoExit -Command .\venv-name\Scripts\activate; jupyter notebook'

# Specify the working directory.
$shortcut.WorkingDirectory = '%USERPROFILE%'

# Set the window style, if needed.
$shortcut.WindowStyle = 7 # Open the PowerShell console window minimized.

$shortcut.Save()

# Test invocation (simulate opening the shortcut interactively)
Invoke-Item $shortcutFile

Note:

• -NoExit keeps the PowerShell session open, so you can inspect what happened on startup; you can remove it once you've verified that launching the notebook works as intended.

• .WindowStyle = 7 starts the PowerShell session minimized (as you're probably not interested in seeing the console window. Thus, in combination with -NoExit, if you want inspect what happened on startup, you'll need to activate the minimized window via the taskbar.

• Assigning to .TargetPath, i.e. specifying the target executable, causes the assigned value to be instantly resolved to a full path:

  • If you assign a mere file name - e.g. powershell.exe - it is looked for in the path, i.e. in the directories listed in the standard $env:PATH environment variable.

    • Caveat: If an executable by that name happens to exist in the same directory as the shortcut file, it is used.

  • Thus, for full robustness you may want to assign a full path, e.g.:

    • With a literal or environment-variable-based path, e.g.:

       .TargetPath = "$env:windir\System32\WindowsPowerShell\v1.0\powershell.exe"
      

    • Or, by performing the $env:PATH lookup at design time; e.g.:

       .TargetPath = (Get-Command powershell.exe).Path
      

• By default, the launched process' working directory is set to:

  • the directory in which the shortcut file is located when the shortcut file is opened interactively (as is typical; via the taskbar or from the Desktop or from File Explorer)

  • by contrast, in programmatic invocation it depends on the caller's working directory, with one subtle distinction.

    • with Invoke-Item, it is the the working directory of the caller's process - which typically differs from PowerShell's working directory.^[1]
    • with Start-Process, it is the working directory (location) of the calling PowerShell session.

  • Therefore, it is best to explicitly assign a working directory, by assigning to the .WorkingDirectory property.

• As shown in the .WorkingDirectory assignment above, you may use cmd.exe-style environment-variable references such as %USERPROFILE%, and such references are equally supported in the .TargetPath, .Arguments and .IconLocation properties.

• General caveat:

  • Despite its name, the .CreateShortcut() method can also open existing shortcut files, e.g. to examine their properties.

  • If you (possibly unwittingly) open an existing shortcut file during an attempt to fully (re)create it, and only fill in some of its properties, any preexisting property values are preserved.

  • Thus, if the intent is to create a shortcut file from scratch, delete any preexisting version first.

• Documentation links:

  • WScript.Shell (WshShell) COM object.
  • .CreateShortcut() method.
  • WshShortcut object.

---

^{[1] PowerShell supports multiple runspaces (threads) per process, each of which can have a separate working directory. This contrasts with the single, process-wide working directory, as used by .NET and other in-process APIs. Therefore, a given PowerShell session's (runspace's) working directory cannot be kept in sync with the process-wide one, and the two typically differ. The upshot is that you should always pass full, file-system-native paths to .NET and other in-process APIs. For more information, see this answer.}

Answered By - mklement0