云原生开发工具数据科学【免费下载链接】docker-stacksReady-to-run Docker images containing Jupyter applications项目地址https://gitcode.com/gh_mirrors/do/docker-stacks点击查看免费下载本文基于仓库中的 开发环境指南 展开系统讲解如何在本地搭建 docker-stacks 项目的完整开发环境一次性安装 Python 依赖与 pre-commit 钩子并在提交 PR 前用make build/image构建镜像、用make test/image运行“镜像自身 所有父镜像”的测试集合。读完本文你可以独立完成一次贴近 CI 的本地检查并理解 Makefile 与测试层级体系IMAGE_PARENT背后的调用逻辑。环境与前置条件在开始之前本机需要满足以下四个前置条件来自 dev-setup.md依赖说明Docker构建与测试的核心引擎pre-commit中的 Hadolint 钩子依赖 Docker 守护进程在运行Python 3.12用于运行测试驱动脚本与 tagging 工具链代码层面也启用了pyupgrade --py312-plusGNU Make驱动 Makefile 中的build/%、test/%等模式化目标Git版本控制与 pre-commit 钩子挂载一次性安装步骤克隆仓库并安装 Python 开发依赖# 克隆仓库后进入目录 cd docker-stacks # 安装 Python 开发依赖 pip install -r requirements-dev.txt # 安装 pre-commit 钩子git commit 时自动运行 linter pre-commit install --install-hooksrequirements-dev.txt 中的依赖均为精确锁定版本其职责可以拆解为三块容器与系统交互docker7.2.0Python 版 Docker SDK测试通过 API 管理容器、plumbum2.0.2tests/run_tests.py 用它拼装并前台执行 pytest 命令测试框架pytest9.1.1、pytest-rerunfailures16.7失败自动重跑规避容器网络抖动、pytest-xdist3.8.0提供--numprocesses并行执行参数工具链pre-commit4.6.2、requests、tenacity重试装饰器用于 API 轮询等待、tabulate、python-dateutil。pre-commit install --install-hooks会把 .pre-commit-config.yaml 中定义的钩子注册到本地 git hooks此后每次git commit都会对改动文件自动执行 pyupgrade、isort、black、ruff、flake8、shfmt、shellcheck、hadolint、yamllint、markdownlint、nbstripout 等检查。配置中还包含ci: autoupdate_schedule: monthly说明钩子版本由 pre-commit.ci 每月自动更新。PR 提交前检查清单Pre-PR checklist原文档给出的三步检查是本地验证的核心流程# 1. 运行全部 linter包括 mypy pre-commit run --all-files --hook-stage manual # 2. 构建你修改的镜像 make build/image-name # 3. 运行该镜像的测试 make test/image-name其中image-name替换为你修改的镜像目录名如docker-stacks-foundation、base-notebook、scipy-notebook。下面结合仓库源码逐条解析其底层行为。第一步为什么必须加--hook-stage manual从 .pre-commit-config.yaml 的源码结构看mypy和basedpyright两个静态类型钩子均显式声明了stages: [manual]# To work around this we run mypy only in manual mode # So it wont run as part of git commit command, # but it will still be run as part of pre-commit workflow and give expected results stages: [manual]原因是 pre-commit 默认只对 git 暂存区中的变更文件运行钩子而mypy --follow-imports依赖整个项目的导入图才能得出正确结论只检查变更文件会漏报。因此git commit时它们被跳过只有手动执行pre-commit run --all-files --hook-stage manual时才会连同全部文件一起运行——这正是文档中第一步命令的由来。另需注意Hadolint 钩子hadolint-docker通过 Docker 运行镜像执行 lint执行第一步时Docker 守护进程必须处于运行状态。第二步make build/image-name在做什么查看 Makefilebuild/%是一个模式匹配目标build/%: DOCKER_BUILD_ARGS? build/%: ROOT_IMAGE?default_root_image build/%: PYTHON_VERSION?3.13 build/%: ## build the latest image for a stack using the systems architecture $(CONTAINER_CLI) build $(DOCKER_BUILD_ARGS) \ --tag $(IMG) \ ./images/$(notdir $) \ --build-arg REGISTRY$(REGISTRY) \ --build-arg OWNER$(OWNER) \ --build-arg ROOT_IMAGE$(ROOT_IMAGE) \ --build-arg PYTHON_VERSION$(PYTHON_VERSION)关键参数均可在命令行覆盖变量默认值含义REGISTRYquay.io镜像注册表前缀OWNERjupyter组织名最终镜像引用为$(REGISTRY)/$(OWNER)/imageROOT_IMAGEdefault_root_image仅对docker-stacks-foundation生效默认使用 Dockerfile 中 sha 固定的根镜像PYTHON_VERSION3.13仅对docker-stacks-foundation生效控制基础层的 Python 版本DOCKER_BUILD_ARGS空追加任意 build 参数的透传口Makefile 还有两个值得注意的工程细节BuildKit 始终启用export DOCKER_BUILDKIT:1保证构建使用 BuildKit 执行器容器引擎自动探测CONTAINER_CLI?$(if $(shell command -v docker),docker,container)会在系统装有docker时优先使用它否则回退到 Apple 的container框架并相应调整image ls、image prune的参数差异见 Makefile。第三步make test/image-name与父镜像测试传播test/%目标并不直接调用 pytest而是委托给 tests/run_tests.pytest/%: ## run tests against a stack python3 -m tests.run_tests \ --registry $(REGISTRY) \ --owner $(OWNER) \ --image $(notdir $)而 tests/run_tests.py 内部通过 plumbum 执行python3 -m pytest --numprocesses auto -m not info test_dirs \ --registry ... --owner ... --image ...这里--numprocesses auto即上文pytest-xdist提供的并行能力-m not info会跳过标记为info的信息性测试。真正的关键在于传入的test_dirs由 tests/hierarchy/get_test_dirs.py 递归计算def get_test_dirs(image: str | None) - list[Path]: test_dirs get_test_dirs(IMAGE_PARENT[image]) # 先递归取父镜像的测试目录 current_test_dir IMAGE_SPECIFIC_TESTS_DIR / image assert current_test_dir.exists(), ... test_dirs.append(current_test_dir) return test_dirs而IMAGE_PARENT定义在 tests/hierarchy/images_hierarchy.py即镜像层级关系IMAGE_PARENT { docker-stacks-foundation: None, base-notebook: docker-stacks-foundation, minimal-notebook: base-notebook, scipy-notebook: minimal-notebook, r-notebook: minimal-notebook, julia-notebook: minimal-notebook, tensorflow-notebook: scipy-notebook, pytorch-notebook: scipy-notebook, datascience-notebook: scipy-notebook, pyspark-notebook: scipy-notebook, all-spark-notebook: pyspark-notebook, }这就解释了原文档中的说明make test/scipy-notebook会依次把docker-stacks-foundation、base-notebook、minimal-notebook、scipy-notebook四个目录分别对应tests/by_image/image下的测试文件全部针对scipy-notebook这个镜像运行一遍。也就是说一个镜像的测试集合 自身测试 所有祖先镜像的测试确保基础层的改动不会破坏下游行为。与之呼应原文档还提示了一个 CI 与本地的差异CI 会把同一套测试集合再针对每一个下游镜像各跑一遍因此在 CI 中修改docker-stacks-foundation会得到跨全部镜像的验证而本地只需make test/docker-stacks-foundation。父镜像缓存陷阱原文档用{note}强调了本地构建的一个隐蔽问题如果父镜像不在本地Docker 会直接从注册表拉取它。这意味着修改了docker-stacks-foundation后若只构建下游镜像而没重新构建父镜像FROM拉到的仍是注册表上的旧版本你的改动不会反映到下游。因此下文的“常见场景”示例中改动基础层时必须按依赖顺序先构建父镜像。常见场景速查原文档给出的三组典型命令# 场景 1修改 foundation 镜像start 脚本、日志等 pre-commit run --all-files --hook-stage manual make build/docker-stacks-foundation make test/docker-stacks-foundation # 场景 2修改 base-notebook必须连同父镜像一起构建 pre-commit run --all-files --hook-stage manual make build/docker-stacks-foundation make build/base-notebook make test/base-notebook # 场景 3构建并测试全部镜像较慢仅在修改 # foundation 或 base 镜像、准备开 PR 前使用 make build-all make test-all从 Makefile 可以看到build-all/test-all展开的ALL_IMAGES是按构建依赖顺序排列的docker-stacks-foundation→base-notebook→minimal-notebook→scipy-notebook→r-notebook→julia-notebook→tensorflow-notebook→pytorch-notebook→datascience-notebook→pyspark-notebook→all-spark-notebook这与IMAGE_PARENT映射完全一致。辅助 Make 目标与延伸阅读除了三步检查清单Makefile 中还提供了若干对本地开发很有用的目标运行make help可查看全部带##注释的目标目标用途make run-shell/image/run-sudo-shell/image进入容器交互式调试后者以 root 运行make check-outdated/image运行 test_outdated.py 生成过期的 mamba/conda 包报告make cont-clean-all停止并删除所有容器清理测试残留make img-rm删除 dangling 镜像与 jupyter 名下镜像回收磁盘make hook/image运行 tagging 后构建钩子写 tags/manifest 并应用标签make docssphinx-build -W构建 HTML 文档更多规范可对照仓库文档阅读Lint 规范Hadolint 忽略规则与# hadolint ignoreDL3001注释用法、测试编写指南、贡献流程钩子行为的 CI 侧对应物见 .github/workflows/pre-commit.yml 与 docker-build-test-upload.yml前者即本文第一步--hook-stage manual命令的 CI 版本后者即第二步、第三步的镜像构建与测试流水线。小结docker-stacks 的本地开发流程可以浓缩为一句话装好依赖与钩子后每次改动都执行「全量 lint → 按依赖序构建镜像 → 运行含父镜像在内的测试集合」三步。理解了IMAGE_PARENT驱动的测试目录递归收集、Makefile 的build/%/test/%参数化设计以及父镜像“本地无则拉注册表”的缓存行为你就能在开 PR 前准确预判 CI 的验证范围避免基础层改动对下游镜像的连锁影响。赞分享云原生开发工具数据科学【免费下载链接】docker-stacksReady-to-run Docker images containing Jupyter applications项目地址https://gitcode.com/gh_mirrors/do/docker-stacks点击查看免费下载相关推荐如何将Imposm3集成到现有GIS工作流中完整指南 ️如何将Imposm3集成到现有GIS工作流中完整指南 ️ OpenStreetMap数据导入工具Imposm3是GIS工作流中的强大助手它能高效地将OS大数据WebDataset与自然语言处理构建高效文本数据加载管道WebDataset与自然语言处理构建高效文本数据加载管道 WebDataset是一个基于Python的高性能I/O系统专为大型和小型深度学习问题设计gsplat 开发环境搭建与工程流程JIT 编译安装、格式化检查、本地测试与文档构建指南gsplat 开发环境搭建与工程流程JIT 编译安装、格式化检查、本地测试与文档构建指南 本文基于 gsplat 官方开发文档 docs/DEV.md htt人工智能计算机视觉3D渲染图形学高性能计算上一篇Inception_v3.tv_in1k进阶技巧特征图提取与可视化完全指南下一篇开源音乐聚合播放器完全指南5大优势打造你的专属音乐空间创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Jupyter docker-stacks 开发环境搭建：本地复刻 CI 的检查、构建与测试流程
云原生开发工具数据科学【免费下载链接】docker-stacksReady-to-run Docker images containing Jupyter applications项目地址https://gitcode.com/gh_mirrors/do/docker-stacks点击查看免费下载本文基于仓库中的 开发环境指南 展开系统讲解如何在本地搭建 docker-stacks 项目的完整开发环境一次性安装 Python 依赖与 pre-commit 钩子并在提交 PR 前用make build/image构建镜像、用make test/image运行“镜像自身 所有父镜像”的测试集合。读完本文你可以独立完成一次贴近 CI 的本地检查并理解 Makefile 与测试层级体系IMAGE_PARENT背后的调用逻辑。环境与前置条件在开始之前本机需要满足以下四个前置条件来自 dev-setup.md依赖说明Docker构建与测试的核心引擎pre-commit中的 Hadolint 钩子依赖 Docker 守护进程在运行Python 3.12用于运行测试驱动脚本与 tagging 工具链代码层面也启用了pyupgrade --py312-plusGNU Make驱动 Makefile 中的build/%、test/%等模式化目标Git版本控制与 pre-commit 钩子挂载一次性安装步骤克隆仓库并安装 Python 开发依赖# 克隆仓库后进入目录 cd docker-stacks # 安装 Python 开发依赖 pip install -r requirements-dev.txt # 安装 pre-commit 钩子git commit 时自动运行 linter pre-commit install --install-hooksrequirements-dev.txt 中的依赖均为精确锁定版本其职责可以拆解为三块容器与系统交互docker7.2.0Python 版 Docker SDK测试通过 API 管理容器、plumbum2.0.2tests/run_tests.py 用它拼装并前台执行 pytest 命令测试框架pytest9.1.1、pytest-rerunfailures16.7失败自动重跑规避容器网络抖动、pytest-xdist3.8.0提供--numprocesses并行执行参数工具链pre-commit4.6.2、requests、tenacity重试装饰器用于 API 轮询等待、tabulate、python-dateutil。pre-commit install --install-hooks会把 .pre-commit-config.yaml 中定义的钩子注册到本地 git hooks此后每次git commit都会对改动文件自动执行 pyupgrade、isort、black、ruff、flake8、shfmt、shellcheck、hadolint、yamllint、markdownlint、nbstripout 等检查。配置中还包含ci: autoupdate_schedule: monthly说明钩子版本由 pre-commit.ci 每月自动更新。PR 提交前检查清单Pre-PR checklist原文档给出的三步检查是本地验证的核心流程# 1. 运行全部 linter包括 mypy pre-commit run --all-files --hook-stage manual # 2. 构建你修改的镜像 make build/image-name # 3. 运行该镜像的测试 make test/image-name其中image-name替换为你修改的镜像目录名如docker-stacks-foundation、base-notebook、scipy-notebook。下面结合仓库源码逐条解析其底层行为。第一步为什么必须加--hook-stage manual从 .pre-commit-config.yaml 的源码结构看mypy和basedpyright两个静态类型钩子均显式声明了stages: [manual]# To work around this we run mypy only in manual mode # So it wont run as part of git commit command, # but it will still be run as part of pre-commit workflow and give expected results stages: [manual]原因是 pre-commit 默认只对 git 暂存区中的变更文件运行钩子而mypy --follow-imports依赖整个项目的导入图才能得出正确结论只检查变更文件会漏报。因此git commit时它们被跳过只有手动执行pre-commit run --all-files --hook-stage manual时才会连同全部文件一起运行——这正是文档中第一步命令的由来。另需注意Hadolint 钩子hadolint-docker通过 Docker 运行镜像执行 lint执行第一步时Docker 守护进程必须处于运行状态。第二步make build/image-name在做什么查看 Makefilebuild/%是一个模式匹配目标build/%: DOCKER_BUILD_ARGS? build/%: ROOT_IMAGE?default_root_image build/%: PYTHON_VERSION?3.13 build/%: ## build the latest image for a stack using the systems architecture $(CONTAINER_CLI) build $(DOCKER_BUILD_ARGS) \ --tag $(IMG) \ ./images/$(notdir $) \ --build-arg REGISTRY$(REGISTRY) \ --build-arg OWNER$(OWNER) \ --build-arg ROOT_IMAGE$(ROOT_IMAGE) \ --build-arg PYTHON_VERSION$(PYTHON_VERSION)关键参数均可在命令行覆盖变量默认值含义REGISTRYquay.io镜像注册表前缀OWNERjupyter组织名最终镜像引用为$(REGISTRY)/$(OWNER)/imageROOT_IMAGEdefault_root_image仅对docker-stacks-foundation生效默认使用 Dockerfile 中 sha 固定的根镜像PYTHON_VERSION3.13仅对docker-stacks-foundation生效控制基础层的 Python 版本DOCKER_BUILD_ARGS空追加任意 build 参数的透传口Makefile 还有两个值得注意的工程细节BuildKit 始终启用export DOCKER_BUILDKIT:1保证构建使用 BuildKit 执行器容器引擎自动探测CONTAINER_CLI?$(if $(shell command -v docker),docker,container)会在系统装有docker时优先使用它否则回退到 Apple 的container框架并相应调整image ls、image prune的参数差异见 Makefile。第三步make test/image-name与父镜像测试传播test/%目标并不直接调用 pytest而是委托给 tests/run_tests.pytest/%: ## run tests against a stack python3 -m tests.run_tests \ --registry $(REGISTRY) \ --owner $(OWNER) \ --image $(notdir $)而 tests/run_tests.py 内部通过 plumbum 执行python3 -m pytest --numprocesses auto -m not info test_dirs \ --registry ... --owner ... --image ...这里--numprocesses auto即上文pytest-xdist提供的并行能力-m not info会跳过标记为info的信息性测试。真正的关键在于传入的test_dirs由 tests/hierarchy/get_test_dirs.py 递归计算def get_test_dirs(image: str | None) - list[Path]: test_dirs get_test_dirs(IMAGE_PARENT[image]) # 先递归取父镜像的测试目录 current_test_dir IMAGE_SPECIFIC_TESTS_DIR / image assert current_test_dir.exists(), ... test_dirs.append(current_test_dir) return test_dirs而IMAGE_PARENT定义在 tests/hierarchy/images_hierarchy.py即镜像层级关系IMAGE_PARENT { docker-stacks-foundation: None, base-notebook: docker-stacks-foundation, minimal-notebook: base-notebook, scipy-notebook: minimal-notebook, r-notebook: minimal-notebook, julia-notebook: minimal-notebook, tensorflow-notebook: scipy-notebook, pytorch-notebook: scipy-notebook, datascience-notebook: scipy-notebook, pyspark-notebook: scipy-notebook, all-spark-notebook: pyspark-notebook, }这就解释了原文档中的说明make test/scipy-notebook会依次把docker-stacks-foundation、base-notebook、minimal-notebook、scipy-notebook四个目录分别对应tests/by_image/image下的测试文件全部针对scipy-notebook这个镜像运行一遍。也就是说一个镜像的测试集合 自身测试 所有祖先镜像的测试确保基础层的改动不会破坏下游行为。与之呼应原文档还提示了一个 CI 与本地的差异CI 会把同一套测试集合再针对每一个下游镜像各跑一遍因此在 CI 中修改docker-stacks-foundation会得到跨全部镜像的验证而本地只需make test/docker-stacks-foundation。父镜像缓存陷阱原文档用{note}强调了本地构建的一个隐蔽问题如果父镜像不在本地Docker 会直接从注册表拉取它。这意味着修改了docker-stacks-foundation后若只构建下游镜像而没重新构建父镜像FROM拉到的仍是注册表上的旧版本你的改动不会反映到下游。因此下文的“常见场景”示例中改动基础层时必须按依赖顺序先构建父镜像。常见场景速查原文档给出的三组典型命令# 场景 1修改 foundation 镜像start 脚本、日志等 pre-commit run --all-files --hook-stage manual make build/docker-stacks-foundation make test/docker-stacks-foundation # 场景 2修改 base-notebook必须连同父镜像一起构建 pre-commit run --all-files --hook-stage manual make build/docker-stacks-foundation make build/base-notebook make test/base-notebook # 场景 3构建并测试全部镜像较慢仅在修改 # foundation 或 base 镜像、准备开 PR 前使用 make build-all make test-all从 Makefile 可以看到build-all/test-all展开的ALL_IMAGES是按构建依赖顺序排列的docker-stacks-foundation→base-notebook→minimal-notebook→scipy-notebook→r-notebook→julia-notebook→tensorflow-notebook→pytorch-notebook→datascience-notebook→pyspark-notebook→all-spark-notebook这与IMAGE_PARENT映射完全一致。辅助 Make 目标与延伸阅读除了三步检查清单Makefile 中还提供了若干对本地开发很有用的目标运行make help可查看全部带##注释的目标目标用途make run-shell/image/run-sudo-shell/image进入容器交互式调试后者以 root 运行make check-outdated/image运行 test_outdated.py 生成过期的 mamba/conda 包报告make cont-clean-all停止并删除所有容器清理测试残留make img-rm删除 dangling 镜像与 jupyter 名下镜像回收磁盘make hook/image运行 tagging 后构建钩子写 tags/manifest 并应用标签make docssphinx-build -W构建 HTML 文档更多规范可对照仓库文档阅读Lint 规范Hadolint 忽略规则与# hadolint ignoreDL3001注释用法、测试编写指南、贡献流程钩子行为的 CI 侧对应物见 .github/workflows/pre-commit.yml 与 docker-build-test-upload.yml前者即本文第一步--hook-stage manual命令的 CI 版本后者即第二步、第三步的镜像构建与测试流水线。小结docker-stacks 的本地开发流程可以浓缩为一句话装好依赖与钩子后每次改动都执行「全量 lint → 按依赖序构建镜像 → 运行含父镜像在内的测试集合」三步。理解了IMAGE_PARENT驱动的测试目录递归收集、Makefile 的build/%/test/%参数化设计以及父镜像“本地无则拉注册表”的缓存行为你就能在开 PR 前准确预判 CI 的验证范围避免基础层改动对下游镜像的连锁影响。赞分享云原生开发工具数据科学【免费下载链接】docker-stacksReady-to-run Docker images containing Jupyter applications项目地址https://gitcode.com/gh_mirrors/do/docker-stacks点击查看免费下载相关推荐如何将Imposm3集成到现有GIS工作流中完整指南 ️如何将Imposm3集成到现有GIS工作流中完整指南 ️ OpenStreetMap数据导入工具Imposm3是GIS工作流中的强大助手它能高效地将OS大数据WebDataset与自然语言处理构建高效文本数据加载管道WebDataset与自然语言处理构建高效文本数据加载管道 WebDataset是一个基于Python的高性能I/O系统专为大型和小型深度学习问题设计gsplat 开发环境搭建与工程流程JIT 编译安装、格式化检查、本地测试与文档构建指南gsplat 开发环境搭建与工程流程JIT 编译安装、格式化检查、本地测试与文档构建指南 本文基于 gsplat 官方开发文档 docs/DEV.md htt人工智能计算机视觉3D渲染图形学高性能计算上一篇Inception_v3.tv_in1k进阶技巧特征图提取与可视化完全指南下一篇开源音乐聚合播放器完全指南5大优势打造你的专属音乐空间创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考