跳转到内容
搜索 Fedora 文档

    浏览当前文档目录

    Fedora 工具链与多版本共存

    Fedora 的版本节奏快,工具链更新也快:同一台机器上同时需要多个语言版本是常态。本页只讲组织方式——哪些东西跟着系统走,哪些必须装进隔离环境。落到具体做法,见用 Toolbox 做隔离开发环境与Fedora 容器与 rootless。

    系统 Python 的约束:以官方 Python 章节为准

    Section titled “系统 Python 的约束:以官方 Python 章节为准”

    Fedora 的 Python 打包与版本策略由官方 Packaging Guidelines 的 Python 章节规定:系统 Python 的约束、打包与命名规则、以及多版本共存方式,都以该章节为准——这一章本身是 rpm 打包规范的一部分。

    这条约束的含义不是「不能升级 Python」,而是先分清你要动的是哪一个 Python:

    • 系统 Python 是发行版的一部分,系统工具依赖它;改动它的收益不在你的项目里,风险却在。
    • 项目运行时 才是你要控制的东西:把它放进隔离环境,系统那一份保持原样。
    • 判断依据不是博客:命名、依赖与模块路径怎么写,官方那一章都有规定;按它的表达方式组织多版本,才谈得上可维护。

    官方 Quick Docs 在 Adding and managing software 之下提供包管理与仓库管理文档:从 dnf 的日常用法到 Fedora 仓库的增删,都是工具链动作的前置知识。

    装工具链之前,先把这三件事分清楚:

    同一个「装个新版本」的需求,有三档做法,隔离强度与成本依次上升:

    做法隔离范围代价
    语言自带的虚拟环境只隔离依赖目录与系统共享解释器与系统库
    Toolbx 容器完整的命令行环境与宿主机仍有集成
    通用容器镜像即环境构建与数据管理要自己扛
    • 只需要隔离依赖:项目内的虚拟环境(Python 的 venv、Node 侧的版本管理器等)够用时,不要引入更重的东西。
    • 需要隔离整套工具链:用 Toolbox 做隔离开发环境用几条命令就能拿到一个装了常用工具与文档的环境。
    • 需要复现与分发:Fedora 容器与 rootless把环境写进镜像,代价是构建与数据卷要自己管。

    从别的发行版带来的习惯:alternatives 与 SCL

    Section titled “从别的发行版带来的习惯:alternatives 与 SCL”

    从 EL 系过来的人,往往习惯用 alternatives 切系统默认版本,或用 SCL 那一套并行软件集合。到了 Fedora 语境,先做两件事再决定用不用:

    1. 找对应关系:你要的东西在官方文档里叫什么、由哪一章规定——Python 的场景就是上一节的 Packaging Guidelines 章节。
    2. 算影响面:alternatives 改的是系统级默认指向,所有用户与所有服务都会跟着变。除非这一步是刻意的、并且准备了回退方案,否则不要用它来满足「我的项目需要另一个版本」。

    本页不假设 alternatives 或 SCL 在 Fedora 上是你该走的路。取舍原则只有一条:能用隔离解决的问题,不要用系统级替换解决——这是判断方法,不是对某个方案的背书。

    隔离环境的价值在于「可以扔掉重来」。要让这句话成立,环境本身必须先被描述出来:

    • 写进项目里:解释器与依赖的版本、必需的系统库,都进版本库(锁文件或环境定义文件)。
    • 给环境起名字:容器或工具箱按项目命名,别让一堆默认名堆在一起——半年后没人敢删。
    • 一条进入命令:新人拿到仓库之后,应该只差一条命令就能进入可用的工具链环境。
    • 定期重建:环境过期就重建,不要在隔离环境里做手工修补——那等于把宿主机上的混乱换个地方重演。
    • 「系统里装一个全局版本最省事」:省下的是今天的时间,付出的是系统工具与项目依赖互相牵扯的成本。
    • 「虚拟环境就等于隔离」:虚拟环境只管依赖,解释器与系统库仍与宿主机共享。
    • 「隔离环境里可以随便跑不可信脚本」:官方对 Toolbx 的定位有明确提醒,见用 Toolbox 做隔离开发环境。
    • 「换个发行版的教程照抄就行」:打包规则是按发行版写的;跨发行版照抄,踩坑点通常在命名与路径规则上。