开发工具代码编辑器数据科学【免费下载链接】positronPositron, a next-generation data science IDE项目地址https://gitcode.com/gh_mirrors/po/positron点击查看免费下载导读本指南完整讲解 Positron 仓库内置的本地 QA 环境工具npm run pwbdocker/environments/wb-local/README.md 为官方文档。它能在你本机的 Docker 中同时运行 Positron下一代数据科学 IDE与 Posit Workbench原 RStudio Workbench 的服务器发行版并按你指定的版本组合一键安装、启动、暂停与清理整条技术栈。读完本文你将掌握版本选择器与非交互式安装、自定义 Positron 构建的替换--positron-build、多操作系统测试容器Ubuntu/Rocky/openSUSE、受管数据源凭据Databricks/Snowflake/Azure、自动停机TTL与常见故障排查等完整实战能力并理解脚本底层workbench-local.sh、install-workbench.sh 等的实现原理。环境概览一次命令启动的两套产品npm run pwb是对bash docker/environments/wb-local/workbench-local.sh的 npm 封装见 package.json。它编排一套由三个容器组成的 Docker Compose 栈定义见 docker-compose.workbench.ymltest运行 Workbench Positron 的主容器默认镜像ghcr.io/posit-dev/positron-ubuntu24:24.18.0暴露 8787Workbench、8080、5900、9323 等端口postgrese2e 测试用的 Postgres 数据库镜像ghcr.io/posit-dev/positron-postgres:24.18.0connectPosit Connect 发布服务器镜像ghcr.io/posit-dev/connect:latest用于测试内容发布链路。test容器以 sleep 循环作为 entrypointcommand: /bin/bash -c while true; do sleep 3600; doneWorkbench 服务本身由安装脚本写入的 supervisord 管理而不是容器入口——这是理解“容器已启动但 8787 可能还没通”的关键。前置条件与首次启动硬件与系统要求官方文档给出的最低门槛Docker Desktop 且配置 8 CPU、16 GB 内存。可选依赖fzf用于方向键选择器没有时退化为数字编号提示brew install fzf # macOS sudo apt install fzf # Debian/Ubuntu winget install junegunn.fzf # Windows conda install -c conda-forge fzf # conda 环境首次启动四步GitHub 容器仓库登录首次被提示输入密码时输入你的GitHub Personal Access Token而非 GitHub 密码该 token 需要read:packages权限docker login ghcr.io -u your_github_username放置许可文件把workbench.lic和connect.lic放到docker/environments/wb-local/目录下connect.lic会被 CR 清洗后挂载到connect/connect.lic详见后文。生成.env首次运行会从 .env.example 自动复制出.env若其中WB_PASSWORD未设置脚本会通过/dev/tty提示你输入。敏感值如受管凭据存放在团队 1Password。启动npm run pwb首次运行会弹出两个版本选择器Positron 与 Workbench随后完成安装并拉起整个栈。完成后访问http://localhost:8787用user1登录密码即.env中的WB_PASSWORD。认证的底层实现源码佐证脚本并不要求你手动docker login。wb_ensure_authworkbench-local.sh 中的函数会依次优先使用显式的GITHUB_TOKEN环境变量或.env否则借用gh auth login登录后的 tokengh auth token再通过 GitHub 的X-OAuth-Scopes响应头检查该 token 是否具备read:packages缺失时给出针对性修复提示gh auth refresh -h github.com -s read:packages。只有在你尚未登录 ghcr.io 时它才会用该 token 自动执行docker login ghcr.io——刻意避免覆盖已存在的专用read:packagesPAT。命令速查表以下是npm run pwb的完整命令参考npm run pwb -- --help在终端中输出同样的内容命令作用npm run pwb拉起栈。首次运行选择版本并安装已安装重启并显示状态。可随时安全重跑npm run pwb -- --reinstall重新运行选择器并重装用于切换 Positron / Workbench 版本npm run pwb -- --credentialstype以受管数据源连接安装databricks、snowflake或azurenpm run pwb -- --workbenchrelease\|daily\|URL --positronrelease\|daily\|TAG跳过版本选择器无 TTY 时必需Agent、CI、管道运行npm run pwb -- --positron-buildrun\|file用 GitHub Actions 运行产物或本地 tarball 替换官方 Positron 构建npm run pwb -- --vsixfile为user1安装扩展.vsix可重复指定npm run pwb -- --ttl N设置自动停机时间为 N 分钟--no-ttl关闭npm run pwb -- status显示容器、已安装版本与 URLnpm run pwb -- logs [svc]跟踪日志rserver默认、connect或容器名npm run pwb -- shell [svc]进入容器 shelltest默认、postgres或connectnpm run pwb -- --osos测试容器宿主 OSubuntu24默认、rocky9或opensuse15npm run pwb -- stop暂停栈容器停止、卷保留npm run pwb -- down拆除栈移除容器与卷自动停机Auto-stop机制默认情况下栈会在60 分钟后自动停止——因为你是通过浏览器工作而非容器容易忘记关闭它空耗 CPU。其实现位于wb_schedule_ttlworkbench-local.sh每次npm run pwb都会重置计时器先取消旧定时器再调度新定时器定时器用nohup挂起一个后台进程只停止它被调度时对应的那个容器实例通过docker inspect记录的容器 ID 比对因此你手动重启后旧的定时任务不会误杀新实例可用--ttl N调整分钟数--no-ttl关闭或直接在.env中设置WB_TTL_MINUTES。版本选择器与固定构建交互式选择Positron先选 Release 或 Daily 频道再选具体版本。版本列表分别来自posit-dev/positron的正式 Releaseprereleasefalse与posit-dev/positron-builds的构建标签见wb_list_positron_releases/wb_list_positron_dailiesworkbench-local-lib.sh。WorkbenchRelease 或 Daily 都解析为该频道当前唯一构建Posit 只发布当前 stable 与当前 daily与 workbench-nightly CI 一致或粘贴自定义包 URL来固定某个具体构建。URL 在安装前会被检查格式、架构与可达性——包括包格式是否匹配目标 OS比如给rocky9栈钉一个.deb会在安装前直接拒绝而不是等到安装时失败。非交互式运行CI / Agent / 管道选择器从/dev/tty读取输入因此 Agent、cron 或管道运行无法应答。此时必须在命令里显式命名构建npm run pwb -- --workbenchdaily --positronrelease npm run pwb -- --reinstall --workbenchdaily --positrondaily # 固定精确构建 npm run pwb -- --workbenchhttps://dl.dailies.rstudio.com/.../rstudio-workbench-...deb --positron2026.08.0-304规则release/daily解析该频道当前构建其他值原样使用--workbench用包 URL--positron用构建标签。.env中的WB_WORKBENCH/WB_POSITRON效果相同。没有 TTY 且未传这些参数时运行会停下并提示你该传什么而不是默默安装列表里第一个构建wb_menu中的read ... /dev/tty失败即触发该提示。需要留意跑依赖新 Positron 特性的 e2e 套件例如 Data Connections时需--positrondailyrelease 构建可能太旧测试会因找不到 UI 元素而失败而非真实缺陷。环境变量兜底.env变量与命令行参数等价WB_WORKBENCH、WB_POSITRON、WB_OS、WB_TTL_MINUTES、WB_PASSWORD、WB_CONTAINER_ARCH等。命令行参数优先级高于.envcmd_up中显式处理--os胜于.env胜于ubuntu24默认值。测试自定义 Positron 构建--positron-build要在一个分支里试用 Workbench可以把它构建替换掉官方 Positronnpm run pwb -- --positron-buildrun ID 或 run URL npm run pwb -- --positron-buildpath/to/positron-workbench-linux-x64-branch.tar.gz为什么必须由 CI 构建Workbench 运行的是 Positron 的独立变体——vscode-reh-web-pwb-linux-arch构建且必须在 Linux 上构建同时它还需要替换成 Workbench 的许可密钥否则 Workbench 拒绝接受、每个会话启动即退出。CI 工作流 build-workbench-linux.yml 同时完成这两件事用scripts/replace-license.sh把 remoteLicenseKey.ts 中的默认公钥替换为测试密钥再执行npm run gulp vscode-reh-web-pwb-linux-x64。因此最省事的途径是让 CI 出构建二选一在 PR 描述中放:workbench每次 push 都会构建并跑该 lane 的 e2e 测试或在分支上以仅 Workbench lane 的方式启动全量套件工作流gh workflow run test-full-suite.yml --ref branch -f run_e2e_linuxfalse -f run_e2e_windowsfalse -f run_e2e_browserfalse -f run_ext_host_testsfalse -f run_e2e_workbenchtrue构建任务结束后把该 run 的 ID 或 URL 传给--positron-build。后续的 Workbench e2e 测试可以取消——构建已经上传完毕。CI 保留该 artifact 仅 1 天所以脚本把下载保留在docker/environments/wb-local/.builds只保留最新一份便于在down或--reinstall后重新应用。run URL 可以指向任意仓库因此 positron-builds 的 release run 也可用。替换流程与状态构建被放到安装器放置 Positron 的位置positron-server/new或positron-server本身视是否存在bundled目录而定status会显示为Positron build它跨stop与重启保留--reinstall或down会把官方 Positron 放回去触碰栈之前脚本会检查下载物是否为该容器架构的 Workbench 构建wb_build_tarball_arch依据 tarball 顶层目录名vscode-reh-web-pwb-linux-arch与文件名判断若构建仍携带默认许可密钥通过wb_default_license_needle从仓库源码 remoteLicenseKey.ts 读取公钥第二行并与out/server-main.js/out/vs/server/node做 grep 比对脚本会给出警告。Apple Silicon 上的注意事项CI 只为 linux-x64 构建 Workbench tarball因此它无法直接运行在 Apple Silicon 默认获得的 arm64 容器中。把栈切换到模拟的 amd64 容器在.env中添加WB_CONTAINER_ARCHamd64这会重建容器所以下一次运行会重新安装且模拟环境下一切都会变慢与--osopensuse15的情况相同。务必把它留在.env中而不是单次传入不带该变量的一次运行会把容器重建回 arm64。反之positron-builds 的 release run 带有 arm64 构建无需任何处理。扩展安装--vsix--vsixfile用 Positron 自己的 CLI 为user1安装扩展与会话内 “Extensions: Install from VSIX” 走同一代码路径sudo -u user1 -H positron-server/bin/positron-server --install-extension可重复传入安装多个。重载已打开的会话即可生效。有个值得注意的行为Positron 构建变更后其首次会话会重装它捆绑的扩展若捆绑副本比你的新会替换掉你装的版本。脚本会在此情况发生时给出警告——先启动一个会话再执行同样的--vsix即可让安装保留下来。选择测试容器 OS栈默认运行在 Ubuntu 24 上。传--os或.env中设置WB_OS即可在其他 e2e lane 覆盖的 OS 上运行同样的 Workbench Positron 安装--osOSe2e lanePR tagubuntu24Ubuntu 24.04workbench默认:workbenchubuntu24Ubuntu 24.04最新稳定版 Workbenchworkbench-stable:workbench-stablerocky9Rocky Linux 9workbench-rocky:workbench-rockyopensuse15openSUSE Leap 15.6workbench-suse:workbench-suse:workbench-all是三条 OS laneUbuntu Rocky openSUSE同时覆盖的简写适合需要全平台验证的改动。它取代那三个 tag 而非叠加——同时带:workbench-all和例如:workbench-rocky的 PR 只会报告:workbench-all。它不隐含:workbench-stable后者改变的是 Workbench 版本而非 OS。npm run pwb -- --osrocky9 --workbenchdaily --positrondaily npm run pwb -- --osopensuse15 --workbenchdaily --positrondailyOS 差异的底层处理OS 之间的差异远不止基础镜像全部由脚本处理。两个 rpm 系 OS 安装.rpm而非用apt装.debRocky 从 feed 的rhel9条目用dnf安装openSUSE 从opensuse15条目用zypper安装。所有 OS 事实包扩展名、文件名前缀、feed 键中的架构 token、容器镜像、存在哪些架构都收敛在wb_os_*系列辅助函数workbench-local-lib.sh中并有一份纯 bash 编写的离线单元测试 scripts/test/workbench-local-lib-test.sh 用 fixture 数据验证 URL 解析与架构重写逻辑。值得注意的架构细节feed 的 key 词汇与文件名词汇不同——rhel9feed 的 key 把 arm64 写作arm64但文件名写作-aarch64.rpmstable URL 解析wb_resolve_stable_url对 Rocky 的路径段与文件名 token 分别重写路径/x86_64→/arm64、文件名-x86_64.rpm→-aarch64.rpm。Workbench 在 supervisord 下运行无论哪个 OS安装器都会把 rserver 与会话启动器session launcher置于supervisord之下Ubuntu 的 universe 仓库、Rocky 的 EPEL、openSUSE 主仓库提供该包与 Posit 自己的 Workbench 容器镜像一致。原因是这些容器没有 systemd而软件包自带的 SysV init 脚本在容器内看不到自己的进程——stop曾是静默空操作restart会再起一个 rserver 卡死在 “Address already in use” 上。supervisord 按 pid 跟踪子进程因此常用动词语义准确且崩溃的 rserver 会自动重启。配置位于/etc/supervisord.confsupervisorctl无需-c即可找到该路径在三套 OS 上都在默认搜索顺序首位docker exec test sudo supervisorctl status docker exec test sudo supervisorctl restart rstudio-server # CI action 与 enforced-settings 测试所做的事 docker exec test sudo supervisorctl start all # npm run pwb 在容器 stop/start 后所做的事注意重启rstudio-launcher会结束所有正在运行的会话所以除非你就是要测试 launcher否则只重启rstudio-server。从 install-workbench.sh 的实现可见更多细节安装器会写一个rserver-foreground包装脚本先等待 launcher 的 socket/var/run/rstudio-server/rserver-launcher.socket就绪再执行rserver --server-daemonize 0解决 rserver 启动时因 socket 缺失而自我关停的问题同时为rstudio-server程序启用stopasgroup/killasgroup让 rserver-httpnginx 前端与 rserver-monitor 随主进程一起停止避免孤儿 rserver-http 一直占住 8787 端口。openSUSE 在 Apple Silicon 上以模拟方式运行Posit 只为x86_64发布 openSUSE 15 的 Workbench 包daily 与 stable feed 均如此不像rhel9和noble有 arm64 构建。因此在 Apple Silicon 上--osopensuse15会把test容器强制为linux/amd64并在模拟下运行——运行开始时脚本会明确告知。它可用CI 就是原生这么跑的但安装与测试会明显慢于另外两个 OS。若请求 arm64 的 openSUSE 构建会以明确消息快速失败wb_os_supports_arch直接拒绝而不是静默下载 x86 的 rpm。切换 OS 必然重装--os改变 compose 的image:Compose 会重建test容器从而清空容器内安装——切换 OS 总是触发重装运行时会提前告知。本地同时只能运行一个栈因为 compose 文件钉死了container_name与固定主机端口。栈已存在时裸npm run pwb会停留在当前 OS“sticky OS”逻辑读取运行中容器的镜像反推 OS因此恢复一个 Rocky 栈不会悄悄重建为 Ubuntu。要刻意迁移请显式传--os或设置WB_OS。受管数据源凭据Managed credentials要测试 Positron 的受管数据源连接Workbench 交给会话的凭据用--credentialstype安装。每次安装只配置一种 provider用--reinstall --credentialstype切换。Type配置内容从.env读取databricks/etc/rstudio/databricks.confdatabricks-enabledDATABRICKS_URL_、DATABRICKS_CLIENT_ID_snowflake/etc/rstudio/snowflake.confallow-refresh-snowflake-rolesSNOWFLAKE_ACCOUNT_、SNOWFLAKE_CLIENT_ID_、SNOWFLAKE_CLIENT_SECRET_azurerserver.conf中的 OpenID 认证 openid-client-secret JIT home 目录AZURE_SERVICE_PRINCIPAL_CLIENT_SECRET_操作步骤把所用 provider 的值填入docker/environments/wb-local/.env模板见 .env.example。每个值都要用单引号包裹——.env由 shell 直接 source含$、空格或#的密钥会被截断或直接报错。名字末尾的下划线本地可省略裸名如SNOWFLAKE_ACCOUNT即 1Password / GitHub secrets 中存储的形式会被当作别名接受wb_map_credential_aliases实现带下划线的正式名优先因其与 Snowflake/Databricks SDK 自动读取的裸名冲突。用该 flag 安装npm run pwb -- --credentialssnowflake若所选 provider 的变量未设置安装会快速失败configure-datasources.sh 对每个 provider 都先检查必需变量缺失即exit 1。实现细节configure-datasources.shdatabricks 会从 URL 提取工作区名生成[workspace]配置节并追加databricks-enabled1snowflake 生成账户配置节并追加allow-refresh-snowflake-roles1azure 追加auth-openid1等 OpenID 设置、写入 0600 权限的openid-client-secret并在/etc/pam.d/common-session中加入pam_mkhomedir.so以实现首次登录 JIT 创建 home 目录。服务访问地址服务URL登录Workbenchhttp://localhost:8787user1/WB_PASSWORD来自docker/environments/wb-local/.envConnecthttp://localhost:3939每次运行 bootstrap 生成Connect 的 API token 由ensure-connect-token.shdocker/environments/wb-local/ensure-connect-token.sh用rsconnect bootstrap获取并写入共享卷/tokens/connect_bootstrap_token已有则直接复用。故障排查首次登录报 Forbidden清除localhost域下的vscode-tkncookie 后刷新即可。每个 Positron 会话启动约 35 秒后退出现象是弹出 “Session Exited” 对话框。检查 launcher 日志中的checkExited ... [description: End of file]docker exec test bash -c grep checkExited /var/log/rstudio/launcher/rstudio-local-launcher-*.log | tail -3这是Workbench launcher 放弃了一个仍在运行的会话并非 Positron 故障。该问题曾出现在 Workbench2026.10.0-daily140在190中消失。裸npm run pwb只会恢复已安装的 Workbench 而不会更新它因此用当前版本重装npm run pwb -- --reinstall --workbenchdaily --positrondaily随后重新应用任何--positron-build。自定义构建的会话立即退出会话输出/var/lib/rstudio-launcher/Local/output/user1/*.stderr报Invalid license key; signature is invalid说明该构建仍带有默认许可密钥。参见上文“测试自定义 Positron 构建”。同一时间只能有一个栈因为container_name: test被钉死。要对比两个 Workbench 版本先down一个再拉起另一个。Apple SiliconConnect 服务慢Connect 以模拟amd64方式运行启动缓慢属预期行为。dependency failed to start: container connect is unhealthy通常与 Connect 许可有关。Connect 无论如何都会启动所以检查它认为自己持有什么docker exec connect /opt/rstudio-connect/bin/license-manager status若 License file status 为空且显示Has-Key: No说明文件根本没被解析所有请求都会返回 402。CRLF 换行的许可文件正是这种表现见下文 Windows 一节缺失或过期的许可同样如此。Windows 支持细节该工具支持 Windows x64与 CI 安装的 amd64 包相同。命令可在 PowerShell 或 Windows Terminal 中照常运行脚本本身在 Git Bash 下执行你无需打开 Git Bash 窗口。唯一的额外设置步骤是让 npm 指向 Git Bashnpm config set script-shell C:\Program Files\Git\bin\bash.exe否则 npm 会通过cmd.exe运行脚本其中裸bash解析为C:\Windows\System32\bash.exe——即 WSL 启动器——脚本会跑进一个通常没有可达 Docker daemon、也没有gh的 Linux 发行版里。脚本能检测出这种情况并明确告知wb_check_shell检查/proc/version是否含microsoft再验证docker info是否可达而不是以晦涩错误失败。真正配好了 WSL 集成、能触达 Docker 的环境可以正常通过检查。Windows 上还有两点行为差异优先使用 PowerShell 或 Windows Terminal而非 minttyGit Bash窗口。npm run pwb -- shell执行docker exec -itfzf选择器也需要真正的 Windows 控制台mintty 不算。许可文件必须是 LF不能是 CRLF。Connect 拒绝解析 CRLF 许可并永远以 402 应答rstudio-server 则直接拒绝。现在两者在进入容器时都会做 CR 清洗脚本与许可文件都经过sed -i s/\r$//Connect 许可在cmd_up中经tr -d \r转写后原子替换到connect/connect.lic因此在 Windows 上保存的许可也能被处理但若以其他方式触发参见故障排查。从源码理解整体工作流一次npm run pwb的完整调用链workbench-local.sh 的cmd_up解析参数--reinstall、--ttl、--os、--positron-build、--vsix等检测架构wb_detect_arch并处理 OS 与平台强制含 Apple Silicon 模拟场景wb_bootstrap_env从.env.example生成并 source.env映射凭据别名必要时从 tty 读取WB_PASSWORDwb_ensure_auth确保 GitHub 认证与 ghcr.io 登录按需预下载--positron-build产物并校验架构处理 Connect 的CONNECT_BOOTSTRAP_SECRETKEY首次用openssl rand -base64 32生成并持久化到.env与connect.licCR 清洗、原子落盘docker compose up -d --remove-orphans拉起三容器栈并等待test健康wb_fetch_scripts把安装器脚本拷入容器并做 CR 清洗、加执行权限已安装且非--reinstallwb_ensure_workbench恢复 supervisord 与 rserver应用自定义构建与 vsix打印就绪状态调度 TTL否则cmd_install选择 Workbench URL 与 Positron tag → install-workbench.sh 在容器内完成建用户、装 Workbench 包、下载 PositronpositronDownload.sh 从positron-buildsrelease 资产按 tag 与架构取positron-workbench-linux-arch-tag.tar.gz、配置数据源、以 supervisord 启动服务。其中 Workbench 包 URL 的解析release/daily 频道、arm64 重写、格式/架构/可达性校验全部收敛在 workbench-local-lib.sh并被 host 侧选择器、容器内安装器install-workbench.sh 与 get-latest-wb-url.sh三处复用配合 scripts/test/workbench-local-lib-test.sh 的离线测试保证规则一致。这套环境与仓库 CI 深度同源Workbench e2e lane 的编排test-full-suite.yml 中的build-workbench→e2e-workbench→e2e-workbench-rocky→e2e-workbench-suse→e2e-workbench-stable串行链使用的正是同一套 Docker 栈与安装逻辑。因此npm run pwb既是本地开发/QA 工具也是理解 Positron Workbench CI 测试链路的可运行缩影。赞分享开发工具代码编辑器数据科学【免费下载链接】positronPositron, a next-generation data science IDE项目地址https://gitcode.com/gh_mirrors/po/positron点击查看免费下载相关推荐Positron Jupyter 本地开发环境用 Docker 一键搭建 JupyterHubTLJH Positron Server 测试栈Positron Jupyter 本地开发环境用 Docker 一键搭建 JupyterHubTLJH Positron Server 测试栈 本文基于开发工具代码编辑器数据科学Positron 上游合并审查实战指南如何用 8 步流程守护 Posit Workbench 集成安全Positron 上游合并审查实战指南如何用 8 步流程守护 Posit Workbench 集成安全 导读 Positron 作为一款下一代数据科学 IDE开发工具代码编辑器数据科学Positron connect-local 实战用 with-connect 拉起临时 Posit Connect 并本地跑通 Publisher e2e 测试Positron connect local 实战用 with connect 拉起临时 Posit Connect 并本地跑通 Publisher e2e开发工具代码编辑器数据科学创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
的核心技术与实战)
