Table of Contents

The Microsoft Authentication Library (MSAL) supports various programming languages and frameworks to simplify the authentication flow against the Microsoft identity platform, which is a prerequisite to invoke APIs such as Microsoft Graph.

In this example, we will write a Python script that performs delegated authentication flow using the user’s credentials. Once authenticated, the script will pull the user’s OneNote data via Microsoft Graph.

Note: While we can also authenticate via app-only access, this is generally scrutinized in larger institutions due to the blast radius. This is because the app can modify other users’ content stored in Microsoft 365 products (emails, calendars, etc).

App Registration and Configuration

Even if you plan to run your program on your local machine, you must register it in the Azure Portal to generate a unique client ID to authenticate.

• Go to https://portal.azure.com/ and sign in.
• Go to App Registrations and register your app.
• Go to the registered app -> Manage (step 1) -> Authentication (step 2). Ensure the following configurations exist:
  • A Mobile and desktop applications platform with the redirect URI set as http://localhost (step 3).
  • The Access tokens (used for implicit flows) option is checked (step 4).

• Go to the registered app -> Manage (step 1) -> API permissions (step 2).
• Add the permissions you need (step 3). OneNote’s permissions are added in this example because the script will query OneNote via Microsoft Graph.
• Before we can call the Microsoft Graph API, these permissions must have green check marks (step 5), accomplished by clicking the Grant admin consent button (step 4). If this button is grayed out, request your institution’s Azure administrators to perform this step on your behalf.

Custom Python Program

Now that the app is registered and configured in the Azure Portal, we can work on the custom script.

Install the msal library.

# requirements.txt

requests
msal

Define the needed variables. The client ID and tenant ID can be retrieved from your registered app in the Azure Portal.

import msal
import requests

CLIENT_ID = '[YOUR_CLIENT_ID]'
TENANT_ID = '[TENANT_ID]'
AUTHORITY = f'https://login.microsoftonline.com/{TENANT_ID}'
SCOPES = ['Notes.Read', 'User.Read']

A function to perform the authentication and to retrieve the access token. MSAL will seamlessly create a web server running on localhost to accept the incoming token data (hence, the need to configure the redirect URI in the Azure Portal).

def get_access_token():
    app = msal.PublicClientApplication(CLIENT_ID, authority=AUTHORITY)
    result = app.acquire_token_interactive(scopes=SCOPES)
    access_token = result['access_token']

    return access_token

A simple function to query OneNote pages using Microsoft Graph.

def get_onenote_pages(access_token):
    url = 'https://graph.microsoft.com/v1.0/me/onenote/pages'

    headers = {
        'Authorization': f'Bearer {access_token}',
        'Accept': 'application/json'
    }

    response = requests.get(url, headers=headers)
    response.raise_for_status()

    return response.json()

Finally, run the app to test if the app registration and configuration are set up correctly in the Azure Portal.

def run():
    access_token = get_access_token()
    print(access_token)

    onenote_pages = get_onenote_pages(access_token)
    print(onenote_pages)


if __name__ == '__main__':
    run() 

The post MSAL: Delegated Access Authentication appeared first on My Shitty Code.

Table of Contents

There are various ways for a Cloud Run instance to connect to a Cloud SQL instance. Regardless of the solutions, if both resources reside in the same GCP organization, connecting using a Cloud SQL’s private IP with SSL/TLS encryption is highly recommended to prevent network traffic from going out to the internet.

It is possible to have a Cloud SQL instance with both private and public IPs enabled, and there are legitimate reasons for doing so. For example, it allows the developers to connect to the Cloud SQL instance outside the GCP environment. However, utmost care is needed to ensure the private IP is always used when connecting from the Cloud Run instance.

This article evaluates the pros and cons of each solution and provides some recommendations.

Cloud SQL Configuration

For consistency’s sake, SSL/TLS encryption is enabled on the Cloud SQL instance using client certificates.

A client certificate is also created.

Note: Some solutions, such as Cloud SQL Proxy and Cloud SQL Language Connectors, do not need the client certificate. So, these steps can be safely skipped. From the documentation:

With Cloud SQL Auth Proxy and Cloud SQL Connectors, client and server identities are also automatically verified regardless of the SSL mode setting.

Options

Option A: Cloud SQL Language Connectors

This solution uses Cloud SQL Language Connectors, a programming language library maintained by Google.

The following configurations are NOT required:

• SSL certificates in the Cloud SQL instance
• Cloud SQL volume mounting in the Cloud Run instance.

Python App

import os

from google.cloud.sql.connector import Connector, IPTypes

# ... simplified for brevity

connector = Connector(IPTypes.PRIVATE)  # use Private IP

connector.connect(
  os.getenv('DB_INSTANCE_CONNECTION_NAME'),  # project:region:instance
  'pymysql',
  user=os.getenv('DB_USER'),
  password=os.getenv('DB_PASS'),
  db=os.getenv('DB_NAME'),
)

Pros

• Very concise configuration in both IaC and application code since there’s no need to manage client certificates.

Cons

• Only supports Python, Java, Go, and Node.js.

Option B: Managed Cloud SQL Proxy in Cloud Run

This solution uses a managed Cloud SQL Proxy that is configurable directly in the Cloud Run instance. Once configured, a Cloud SQL volume mount is created in the Cloud Run instance.

Python App

import os

import pymysql

# ... simplified for brevity

pymysql.connect(
  database=os.getenv('DB_NAME'),
  user=os.getenv('DB_USER'),
  password=os.getenv('DB_PASS'),
  unix_socket=f'/cloudsql/{os.getenv("DB_INSTANCE_CONNECTION_NAME")}',  # /cloudsql/project:region:instance
)

Pros

• Very concise configuration in both IaC and application code since there’s no need to manage SSL certificates.

Cons

• It doesn’t work if the Cloud SQL instance has both public IP and private IP enabled. There’s no way to specify which IP to use, and Cloud SQL Proxy automatically uses the public IP if it exists.
  • Note: If you know how to pull this off, please drop a comment below.
• Additional configurations must be considered when running in production, which introduces many points of failure.
• It may exceed the default Cloud SQL Admin API quota limit.

Option C: Manually Configure Cloud SQL Proxy

This solution manually configures Cloud SQL Proxy via Dockerfile instead of relying on the managed Cloud SQL volume mount from Cloud Run.

Dockerfile

FROM python:3.12-alpine

RUN apk update && apk add curl

WORKDIR /app

COPY . /app

RUN pip install --no-cache-dir -r requirements.txt

EXPOSE 8080

RUN curl -o cloud-sql-proxy https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.12.0/cloud-sql-proxy.linux.amd64
RUN chmod +x cloud-sql-proxy

CMD ["sh", "-c", "./cloud-sql-proxy --private-ip --port 3306 ${DB_INSTANCE_CONNECTION_NAME} & sleep 5 && python app.py"]

Python App

import os

import pymysql

# ... simplified for brevity

pymysql.connect(
  host=os.getenv('DB_HOST'),  # 127.0.0.1
  database=os.getenv('DB_NAME'),
  user=os.getenv('DB_USER'),
  password=os.getenv('DB_PASS'),
)

Pros

• Very concise configuration in both IaC and application code since there’s no need to manage client certificates.
• Unlike the managed Cloud SQL Proxy volume mount solution, this solution will work even if the Cloud SQL instance has both private and public IPs.

Cons

• Need to manage the Cloud SQL Proxy installation and configuration in the Dockerfile.
• All the cons described in the managed Cloud SQL Proxy solution above still apply here.

Option D: Use Cloud SQL’s Private IP and Client Certificate

Instead of relying on external tools/libraries, the application code connects directly to the Cloud SQL instance using the private IP where the client certificate is also provided.

Python App

import os

import pymysql

# ... simplified for brevity

pymysql.connect(
  host=os.getenv('DB_HOST'), # Cloud SQL's Private IP
  database=os.getenv('DB_NAME'),
  user=os.getenv('DB_USER'),
  password=os.getenv('DB_PASS'),
  ssl={
    'ca': os.getenv('DB_SSL_SERVER_CA'),     # /app/certs/ca/server-ca.pem
    'cert': os.getenv('DB_SSL_CLIENT_CERT'), # /app/certs/cert/client-cert.pem
    'key': os.getenv('DB_SSL_CLIENT_KEY'),   # /app/certs/key/client-key.pem
    'check_hostname': False,
  }
)

Note: The hostname checking must be disabled because the database host (Cloud SQL’s Private IP) will never
match the common name specified in the certificate. If the hostname checking is not disabled, it will produce the following error:

Error connecting to database: (2003, “Can’t connect to MySQL server on ’10.x.x.x’ ([SSL: CERTIFICATE_VERIFY_FAILED]
certificate verify failed: IP address mismatch, certificate is not valid for ’10.x.x.x’. (_ssl.c:1000))”)

Pros

• No additional wrappers like Cloud SQL Proxy or Cloud SQL Language Connectors are required.

Cons

• Additional configurations and complexity on the IaC and application code are needed to manage and ingest the client certificate securely.

Recommendations

Best Solution – Option A

Use Cloud SQL Language Connectors if your app uses one of the supported programming languages (Python, Java, Go, or Node.js).

It eliminates many unnecessary configurations on the IaC code and application code. In other words, there’s no need to do the following:

• Create a client certificate for Cloud SQL.
• Store server certificate, client certificate, and client key in Secret Manager securely.
• Mount files containing the server certificate, client certificate, and client key as volumes in the Cloud Run instance.
• Pass certificate information to the application code via environment variables.

None of the above is needed.

Less codebase = Less chance of errors.

Distance Next Best Solution – Option D

Connect directly using the Cloud SQL instance’s Private IP and client certificate.

It eliminates the need to rely on additional cloud configuration or external library (i.e., fewer points of failure).

However, it introduces additional configurations in IaC and application code to maintain and ingest the certificate described above.

Least Favorite Solution – Option B & C

While both Cloud SQL Proxy solutions (volume mount in the Cloud Run instance or installing it directly via Dockerfile) don’t require a client certificate, they come with additional considerations and complexities when running in production.

Furthermore, the volume mount solution won’t work if the Cloud SQL instance has both private and public IPs.

The post Cloud Run: Connecting to Cloud SQL with Private IP and SSL appeared first on My Shitty Code.

Table of Contents

What is GitHub Copilot

GitHub Copilot is dubbed “an AI pair programmer” to help us write code faster, using a generative AI model developed through a collaboration between GitHub, OpenAI, and Microsoft Azure AI.

These days, there are nothing short of AI-powered tools that can do similar things in this space. For example, Tabnine, Google’s Duet AI, Meta’s CodeCompose (currently used internally at Meta), and Code Llama.

Prerequisites

You need to obtain a paid license before you can use GitHub Copilot.

Then, install the GitHub Copilot extension in your favorite IDE. In this post, I’m using VS Code because GitHub also created the GitHub Copilot Labs extension that is not available in JetBrains IDEs (e.g., IntelliJ, PyCharm, etc.).

Tips & Tricks

Below is a compilation of cool tricks you can do with GitHub Copilot using VS Code.

Type Descriptive Code

The easiest way to get started is to continue with your typical coding. If you type descriptive variables or function names, GitHub Copilot can provide better code suggestions.

You can also cycle through the inline suggestions using shortcut keys in your favorite IDE.

Type Comments First

The challenge of typing very descriptive variables or function names is they get very lengthy, and you risk having your favorite code format tool complaining about the line length.

So, it helps to write them as comments first before you write your code. You can comment above the function you want to create or even at the top of the file.

The most significant advantage of this approach is if your multline comments are clear and precise, it sets proper guardrails for GitHub Copilot to provide better code suggestions based on the context you define (i.e., less hallucination).

View Multiple Suggestions

Sometimes, you want to browse all suggestions all at once.

In that case, identify the shortcut key listed under github.copilot.generate first.

Then, type the comment and press the shortcut key in the next new line to open up the suggestions in a new tab. You can browse the suggestions and accept the one you like.

Generate Test Cases

One of the best uses of GitHub Copilot is the ability to create test cases, especially if your function has excellent documentation.

Here’s another example where you want to generate multiple assertions.

Perhaps you don’t want to lump multiple assertions into one test case because if one of the assertions fails, the entire test case fails.

In this example, I’m using the pytest framework, which has a decorator that allows the parameterization of the test function’s argument(s). To refactor the existing test case, GitHub Copilot Labs’ custom brush converts a single test case into 5 test cases.

Internationalization

If you are building an app that users worldwide will use and want to serve the text based on regions, you can easily convert the text to different spoken languages.

A faster way to perform language conversion is to use GitHub Copilot Labs’ custom brush to convert multiple lines simultaneously.

Generate Realistic Test Data

Sometimes, you want to generate realistic data for your program or test cases.

You can also define the preferred data structure.

Perhaps you want to know what world leaders like to eat. As you can see, GitHub Copilot can determine the country leaders and associate the dishes relevant to that country.

Learn IDE’s Shortcut Keys

I have used IntelliJ IDEA as my primary IDE for almost 20 years. My brain is fully wired with that particular IDE’s shortcut keys. To my disappointment, GitHub doesn’t create the GitHub Copilot Labs extension for JetBrains products.

To challenge myself, I want to learn similar shortcut keys for VS Code. While I can search the web for it, the easiest way is to do it directly in the code editor so that it doesn’t take my attention away during code development.

Converse with “q: ” and “a: ”

You can ask GitHub Copilot anything using the q: and a: construct, even though it’s unrelated to your codebase.

You can use the same construct to ask GitHub Copilot to explain the codebase.

You can even argue with GitHub Copilot and defend Chuck Norris’ honor!

Fix Bug

You can attempt to fix unobvious bugs. This feature is far from perfect., but it’s worth trying out.

List Steps

Perhaps you inherited a project from a previous team and struggled to understand the written code. In this case, you can list the steps in the codebase.

Explain Code

Maybe you don’t want to clutter the existing codebase with unnecessary comments because you don’t own the codebase. In this case, you can use GitHub Copilot to explain the code instead.

Translate Codebase to Another Programming Language

You can also translate a block of highlighted code to another programming language.

Copilot Labs Settings

If you often use the Copilot Labs features, there are 2 settings worth enabling to provide quick access to them.

Show Brushes Lenses

When enabled, all brush functions (fix bug, list steps, custom, etc.) are made available when you move your cursor within the function or highlight the code.

Show Test Generation Lenses

When enabled, it displays “Suggest test” on the function that quickly brings you to the Copilot Labs’ Test Generation section.

Please note the Copilot Labs’ Test Generation currently works with Javascript and Typescript (as of 2023-09-03).

What Else

Do you know other cool tricks that are not listed here? If so, drop your comments below. I’m interested to learn from you.

The post GitHub Copilot: 10+ Ways to Increase Productivity appeared first on My Shitty Code.

PROBLEM: MODIFYING EXISTING RESOURCE NAME

Using a simple resource block below as an example…

resource "random_pet" "current" {}

On apply, one resource is created and the state now tracks that resource.

$ terraform state list
random_pet.current

When changing the resource name from current to new…

resource "random_pet" "new" {}

The generated plan indicates the resource will be destroyed and recreated, which may cause potential data loss (ex: if the resource is a database) or unintended ripple effects (because the resource ID has changed).

In this case, congratulations! We have become pet killers.

# random_pet.current will be destroyed
# (because random_pet.current is not in configuration)
- resource "random_pet" "current" {
    - id        = "willing-fowl" -> null
    - length    = 2 -> null
    - separator = "-" -> null
  }

# random_pet.new will be created
+ resource "random_pet" "new" {
    + id        = (known after apply)
    + length    = 2
    + separator = "-"
  }

Plan: 1 to add, 0 to change, 1 to destroy.

Solving With Terraform Earlier Than 1.1

Before Terraform 1.1, the only way to change the resource name without recreating the resource is to use terraform state mv.

$ terraform state mv random_pet.current random_pet.new
Move "random_pet.current" to "random_pet.new"
Successfully moved 1 object(s).

We can also verify that the resource name has changed in the state.

$ terraform state list
random_pet.new

Solving With Terraform 1.1

Terraform 1.1 introduced moved block where the state change process can be done directly in Terraform source code without using terraform state mv.

To pull this off, we changed the resource name from current to new. Then, a moved block is added to facilitate the state change without affecting the provisioned resource.

resource "random_pet" "new" {}

moved {
  from = random_pet.current
  to   = random_pet.new
}

Now, we can verify the generated plan to ensure the provisioned resource does not get destroyed and recreated before applying the move.

# random_pet.current has moved to random_pet.new
resource "random_pet" "new" {
  id = "willing-fowl"
  # (2 unchanged attributes hidden)
}

Plan: 0 to add, 0 to change, 0 to destroy.

The state should have the updated resource name.

$ terraform state list
random_pet.new

So, what if the moved block is left in the codebase, and we do another plan or apply?

$ terraform apply
random_pet.new: Refreshing state... [id=willing-fowl]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

As you can see, leaving the moved block in the codebase does not affect the state or the resource, and Terraform is smart enough to ignore it. In another word, once the “move” has occurred, we can safely remove the moved block.

PROBLEM: RESTRUCTURING CODEBASE USING “FOR_EACH”

Let’s try something a little more complicated.

Let’s assume we have 3 random pets where we call the resource block 3 times. Perhaps, you inherited the old codebase from pre v0.13 days where for_each construct was not introduced yet.

resource "random_pet" "a" {}
resource "random_pet" "b" {}
resource "random_pet" "c" {}

Here’s how the state looks like.

$ terraform state list
random_pet.a
random_pet.b
random_pet.c

Let’s assume we want to refactor the existing codebase to leverage the for_each construct.

resource "random_pet" "main" {
  for_each = toset(["a", "b", "c"])
}

Solving With Terraform Earlier Than 1.1

With older version of Terraform, we have to perform the following terraform state mv 3 times.

$ terraform state mv random_pet.a 'random_pet.main["a"]' 
Move "random_pet.a" to "random_pet.main[\"a\"]"
Successfully moved 1 object(s).

$ terraform state mv random_pet.b 'random_pet.main["b"]' 
Move "random_pet.b" to "random_pet.main[\"b\"]"
Successfully moved 1 object(s).

$ terraform state mv random_pet.c 'random_pet.main["c"]' 
Move "random_pet.c" to "random_pet.main[\"c\"]"
Successfully moved 1 object(s).

$ terraform state list 
random_pet.main["a"]
random_pet.main["b"]
random_pet.main["c"]

Solving With Terraform 1.1

To pull this off with Terraform 1.1, we call the moved block 3 times.

resource "random_pet" "main" {
  for_each = toset(["a", "b", "c"])
}

moved {
  from = random_pet.a
  to   = random_pet.main["a"]
}

moved {
  from = random_pet.b
  to   = random_pet.main["b"]
}

moved {
  from = random_pet.c
  to   = random_pet.main["c"]
}

In the generated plan, we want to verify that there are no changes made to the provisioned resources before applying changing the state.

# random_pet.a has moved to random_pet.main["a"]
resource "random_pet" "main" {
  id = "poetic-collie"
  # (2 unchanged attributes hidden)
}

# random_pet.b has moved to random_pet.main["b"]
resource "random_pet" "main" {
  id = "glad-lobster"
  # (2 unchanged attributes hidden)
}

# random_pet.c has moved to random_pet.main["c"]
resource "random_pet" "main" {
  id = "suited-fly"
  # (2 unchanged attributes hidden)
}

Plan: 0 to add, 0 to change, 0 to destroy.

As you can see, we end up with the same outcome.

$ terraform state list
random_pet.main["a"]
random_pet.main["b"]
random_pet.main["c"]

The upside is we can still stick with our terraform apply to adjust the state without using terraform state mv.

LIMITATIONS

It’s worth pointing out that it’s not all sunshine and rainbows here.

The moved block solves just part of the state manipulation problems, and you may still need to use terraform state [action] for other use cases (at least with Terraform 1.1.x).

Limitation #1: Removing Resources(s) from State

In rare cases, you may want Terraform to stop tracking a resource in its state file. Perhaps, you run into a race condition problem when attempting to destroy the resources, which prevents Terraform from completing the process successfully. As a result, all resources are fully destroyed (via “eventual consistency”) but unfortunately, a few non-existent resources are still being tracked in the Terraform’s state file.

In this case, you can’t remove the resource from the state by assigning an empty string…

moved {
  from = random_pet.current
  to   = ""
}

$ terraform apply
╷
│ Error: Invalid expression
│
│   on main.tf line 21, in moved:
│   21:   to   = ""
│
│ A single static variable reference is required: only attribute access and indexing with constant keys. No calculations, function calls, template expressions, etc are
│ allowed here.

… or to null…

moved {
  from = random_pet.current
  to   = null
}

$ terraform apply
╷
│ Error: Invalid address
│
│   on main.tf line 21, in moved:
│   21:   to   = null
│
│ Resource specification must include a resource type and name.
╵

The only way to pull this off is to use terraform state rm.

$ terraform state rm random_pet.current
Removed random_pet.current
Successfully removed 1 resource instance(s).

Limitation #2: Moving Resource(s) Between State Files

The moved block allows us to rename resource or restructure our codebase all within the same state file. However, it is not possible to move resources from one state file to another state file.

For example, let’s assume we have one Terraform workspace that manages the following 3 resources.

# workspace A

resource "google_folder" "a" {
  parent       = "folders/123456789012"
  display_name = "a"
}

resource "google_folder" "b" {
  parent       = "folders/123456789012"
  display_name = "b"
}

resource "google_folder" "c" {
  parent       = "folders/123456789012"
  display_name = "c"
}

… and we want to move resource c to another workspace.

# Workspace A

resource "google_folder" "a" {
  parent       = "folders/123456789012"
  display_name = "a"
}

resource "google_folder" "b" {
  parent       = "folders/123456789012"
  display_name = "b"
}

# Workspace B

resource "google_folder" "c" {
  parent       = "folders/123456789012"
  display_name = "c"
}

The only way to pull this off is to identify the resource ID for c in workspace A first…

# Workspace A

$ terraform state show google_folder.c
# google_folder.c:
resource "google_folder" "c" {
  create_time     = "2022-04-30T15:00:29.114Z"
  display_name    = "c"
  folder_id       = "999999999999"
  id              = "folders/999999999999"
  lifecycle_state = "ACTIVE"
  name            = "folders/999999999999"
  parent          = "folders/123456789012"
}

Then, remove that resource from workspace A’s state.

# Workspace A

$ terraform state rm google_folder.c
Removed google_folder.c
Successfully removed 1 resource instance(s).

Finally, import the resource in workspace B’s state.

# Workspace B

$ terraform import google_folder.c folders/999999999999
google_folder.c: Importing from ID "folders/999999999999"...
google_folder.c: Import prepared!
  Prepared google_folder for import
google_folder.c: Refreshing state... [id=folders/999999999999]

Import successful!

The resources that were imported are shown above. These resources are now in
your Terraform state and will henceforth be managed by Terraform.

The post Terraform: Updating State Using “Moved” Block appeared first on My Shitty Code.

PROBLEM

• You are using GCP JupyterLab.
• You want to adhere to the Python development best practices by not polluting the global environment with your Python packages so that you can generate a cleaner “pip freeze” in the future.
• You want each Notebook file (.ipynb) to have its own environment so that you can run them with different package versions.
• You configured a Python virtual environment, but “pip install” from the Notebook file still installs the packages in the global environment.
• You are fed up.

SOLUTION

Configuring Virtual Environments

In the JupyterLab Notebook’s terminal, create an empty directory to organize all virtual environments.

mkdir virtualenv

Ensure ipykernel is installed. This is used to create new IPython kernels.

python3 -m pip install ipykernel

For each new virtual environment, run the following commands to perform these steps:

• Get into the base virtual environment directory.
• Define a new virtual environment name. Replace [NEW_ENV_NAME] with a new name.
• Create new Python virtual environment.
  • The –system-site-packages option ensures you can still use the “data-sciencey” packages that come pre-installed with the GCP JupyterLab Notebook within your new virtual environment.
• Jump into the newly created virtual environment.
• Create a new IPython kernel.
• Exit from virtual environment.

cd virtualenv
VENV=[NEW_ENV_NAME] # Update this!
python3 -m venv $VENV --system-site-packages
source $VENV/bin/activate
python -m ipykernel install --user --name=$VENV
deactivate

Configuring Notebook File

Create a new Notebook file (.ipynb).

In Select Kernel dialog, select the kernel that you created. In this example, there are 2 new virtual environments (“smurfs” and “thundercats”).

To perform a simple test, install a new package.

%pip install pandas==1.3.0

IMPORTANT: You need to use IPython’s Magics (literally speaking) to ensure the packages are installed in the virtual environment.

• %pip = This uses the pip package manager within the current kernel. Magic!
• ! pip = This uses the pip package manager from the underlying OS. No magic!

From the menu bar, select Kernel -> Restart Kernel and Clear All Outputs… . Always restart the kernel when new packages are installed with %pip.

Inspect the package version. This should show the version you have just installed.

import pandas
print(pandas.__version__)

To verify this actually works, create another Notebook file pointing to another kernel. In this file, install the same package but with different version.

The post Enabling Python VirtualEnv in JupyterLab appeared first on My Shitty Code.