IDE

Coding where the data is

The usual arrangement keeps the tools apart: the data on one side, RStudio or Jupyter on the other, and manual exports in between that must be redone on every update.

Linkr’s IDE puts the code inside the project. Your scripts reach the datasets and databases through stable paths, they leave in the export with everything else, and they are versioned alongside the cohorts and dashboards.

The screen

Four areas side by side: the file explorer on the left, the editor in the middle as tabs, a notebook’s outline, then the output panel on the right. The editor toolbar carries the Run button and, on the right, the settings, keyboard shortcuts, Connections, terminals, and the outline and output toggles. Below the screen, the status bar leads to background jobs and to Environments.

1stays <- sql_query("SELECT * FROM visit_occurrence")
2nrow(stays)

1fit <- survfit(Surv(days, death) ~ group, stays)
2ggsurvplot(fit)

The output panel separates result types: Console for text, plus dedicated tabs for figures, tables and HTML or markdown renders.

Terminals open as tabs in the editor, from the Terminal icon: a Bash terminal, a Python console, an R console.

The editor’s theme, font and auto-save live in your profile, not here — they are personal preferences, not project settings.

Connections

The Connections panel says which database SQL and the sql_query() function run against. It lists two families: Warehouse databases, that is the databases linked to the project, and Custom connections, specific to the IDE, created with Add connection. Clicking a row makes it the active connection; the choice is saved with the project. The list next to the Run button makes the same choice without opening the panel.

The languages

Notebooks run cell by cell, with an outline on the right listing the cells and their state.

Running

The Run button runs the whole file; its arrow offers four gestures: the file, the selection, the current line, or — in server mode, and outside SQL — the file as a background job.

Keyboard shortcuts are rebindable from the shortcuts window, reachable from the toolbar.

Where your code runs

This is the most important difference between the two deployment modes, and it changes what you can do.

A terminal’s banner always says which of the two you are on.

Reaching the project’s data

Two libraries are available in every Linkr session, one per language. They give you the project’s paths:

import linkr
import pandas as pd

df = pd.read_csv(linkr.datasets_dir() / "cohort.csv")

con = linkr.connect("mimic")          # a database linked to the project, read-only
patients = con.sql("SELECT * FROM person LIMIT 100").df()

library(linkr)

df <- read.csv(file.path(linkr_datasets_dir(), "cohort.csv"))

These functions also work outside Linkr: run on your own machine, the same script falls back to the working directory, with a warning. A script written here therefore stays runnable elsewhere.

Package environments

This is the mechanism that makes an analysis reproducible, and it is worth understanding. It concerns server mode; browser mode has its own rules, below.

Each project has one Python environment and one R environment. You declare your packages there; Linkr installs them in an isolated space belonging to the project. The list and exact versions are versioned with the project, in its environments/ folder.

The consequence is the one you want: a colleague importing your project rebuilds the same environment, with the same versions, and gets the same results.

Declaring packages

The Environments window opens from the status bar, at the bottom of the screen. One tab per language; you add several packages at once, comma-separated, pinning a version where needed: pandas, numpy==1.26. An environment that is still empty offers Install the workspace’s default packages: the starting set defined in the workspace settings.

A badge says where the environment stands: Not built when the list changed without being installed yet, Building… during installation, Build failed if it failed, and Up to date when everything declared is installed. Building is triggered by the Rebuild button, or automatically the first time you run code. The Rebuild automatically option applies each change immediately; turned off, changes wait for the next build.

Updating

Check for updates queries the package repository — on demand, never automatically — and fills the Status column: Up to date, or the version available. Each row has its Update to latest button, and Update all moves every package to its latest version. Either way the environment turns Not built again — or rebuilds at once if Rebuild automatically is ticked.

The Advanced options set where packages come from — the CRAN repository for R, the PyPI index for Python —, useful behind a hospital’s internal mirror. Left blank, they take the workspace’s setting.

Sessions and background jobs

Several sessions

A session is an independent coding workspace, like a second console in RStudio. Useful for leaving a long computation running on one side while exploring on the other.

Each session belongs to one language: an R session only appears on an R script.

Running as a background job

Run file as background job launches the script in a fresh process, followed from the jobs panel at the bottom of the screen. You can close the file, change page: the computation continues, and both its figures and its result table are kept.

Limits and permissions

Running code is Linkr’s most sensitive permission — it allows arbitrary code to run on the server. It is therefore separate from the permission to view a dashboard, and reserved for editing roles.

An administrator can disable code execution entirely on an instance.

The values below are the server-mode defaults; an administrator can adjust them.

Going further

• Datasets — what scripts read and produce.
• Web apps — running a Shiny or Streamlit app from this code.
• Versioning and export — what leaves with your scripts.
• SQL script collections — for SQL meant to be shared.