尧图网页设计 
开发工具CLI【免费下载链接】pipreqspipreqs - Generate pip requirements.txt file based on imports of any project. Looking for maintainers to move this project forward.项目地址https://gitcode.com/gh_mirrors/pi/pipreqs点击查看免费下载pipreqs 是一款根据项目源码中的 import 语句自动扫描并生成requirements.txt的 Python 命令行工具它不需要你提前安装任何依赖也不需要依赖当前 Python 环境里已有的包列表而是从源码出发逆向推导项目真正用到的第三方库。读完本文你将掌握 pipreqs 的安装方式、全部命令行参数PyPI 解析、本地解析、代理、动态版本号、notebook 扫描等、典型使用流程以及它与pip freeze的本质区别并能结合实际源码理解其底层工作原理。安装 pipreqspipreqs 是一个标准的 PyPI 分发包最简单的方式是直接通过 pip 安装pip install pipreqs安装后会在环境中提供pipreqs命令行入口。项目在 pyproject.toml 中声明了该入口指向pipreqs.pipreqs:main因此安装后可以直接在终端调用。精简安装去掉 Jupyter 支持pipreqs 默认附带对 Jupyter Notebook.ipynb的扫描支持这需要引入nbconvert与ipython等较重依赖见 pyproject.toml 中的nbconvert7.11.0、ipython8.12.3。如果你用不到 notebook 扫描功能可以跳过全部依赖只手动安装两个核心运行库pip install --no-deps pipreqs pip install yarg0.1.9 docopt0.6.2其中yarg用于解析 PyPI 的 JSON 接口源码中通过from yarg import json2package导入见 pipreqs.pydocopt用于按命令行帮助文本解析参数见 pipreqs.py。基本用法pipreqs 的核心用法是在命令行传入项目目录路径它会扫描该目录下所有源码文件中的 import 语句去重、过滤标准库再逐个解析出对应的 PyPI 包名与最新版本号最终写入requirements.txt。Usage: pipreqs [options] [path] Arguments: path The path to the directory containing the application files for which a requirements file should be generated (defaults to the current working directory)path是可选的不传时默认使用当前工作目录对应源码 pipreqs.py 中的os.path.abspath(os.curdir)。一个典型示例$ pipreqs /home/project/location Successfully saved requirements file in /home/project/location/requirements.txt生成的requirements.txt形如wheel0.23.0 Yarg0.1.9 docopt0.6.2默认每条依赖使用精确锁定版本。生成前如果目标目录已存在requirements.txtpipreqs 会给出警告并拒绝覆盖必须显式加--force才会重写对应源码 pipreqs.py。命令行选项详解选项说明--use-local只使用本地已安装包的信息不查询 PyPI--pypi-server url指定自定义 PyPI 服务器地址--proxy url指定代理地址参数会透传给 requests 库也可以通过环境变量HTTP_PROXY/HTTPS_PROXY设置--debug输出调试信息将日志级别切换为 DEBUG--ignore dirs...额外忽略的目录多个目录用逗号分隔--no-follow-links不跟随项目中的符号链接--ignore-errors扫描文件时忽略错误打印堆栈并跳过出错文件--encoding charset指定打开文件时使用的编码默认 utf-8--savepath file将依赖列表保存到指定文件--print将依赖列表输出到标准输出--force覆盖已存在的 requirements.txt--diff file将指定文件中的模块与项目实际 import 做对比报告未使用的模块--clean file清理指定文件移除项目未 import 的模块--mode scheme动态版本号模式compat、gt、no-pin见下文--scan-notebooks同时扫描 Jupyter Notebook 文件.ipynb中的 import代理配置--proxy会把同一个 URL 同时用作 HTTP 与 HTTPS 代理源码 pipreqs.py 构造了{http: url, https: url}传入 requests。也可以不传参数直接在终端导出环境变量$ export HTTP_PROXYhttp://10.10.1.10:3128 $ export HTTPS_PROXYhttps://10.10.1.10:1080动态版本号模式--mode支持三种取值由 dynamic_versioning() 实现compat使用兼容运算符如Flask~1.1.2gt使用大于等于运算符如Flask1.1.2no-pin不锁定版本只写包名如Flask不指定--mode时默认使用精确锁定。如果传入了这三种之外的取值程序会抛出ValueError提示只能使用compat、gt或no-pin见 pipreqs.py。依赖对比与清理--diff file解析指定文件如已有的requirements.txt与当前项目实际 import 集合对比列出“文件中存在但项目里没有 import”的模块由 compare_modules() 与 diff() 实现。--clean file更进一步直接重写指定文件删除其中项目并未 import 的模块行由 clean() 实现。如果文件里没有需要清理的模块会提示Nothing to clean in file。笔记本扫描加上--scan-notebooks后pipreqs 会额外把.ipynb视为扫描对象。底层实现中.ipynb文件会先经 ipynb_2_py() 用nbconvert的PythonExporter转成 Python 文本再进入统一的 AST 解析流程。若环境缺少nbconvert/ipython会抛出NbconvertNotInstalled异常提示先安装这两个库见 pipreqs.py 与 handle_scan_noteboooks()。底层原理从 import 到 requirements.txt理解 pipreqs 的“源码驱动”特性关键在于其核心扫描函数get_all_imports()见 pipreqs.py整个流程分为四个阶段1. AST 解析 import。pipreqs 只扫描.py与.pyw两类文件常量DEFAULT_EXTENSIONS [.py, .pyw]对每个文件用ast.parse()生成语法树再遍历所有ast.Import与ast.ImportFrom节点收集模块名。由于是语法树级解析import xml.etree、from sys import argv、import os.path as test这类写法都能被正确识别。2. 清洗与去重。对收集到的模块名做三件事取顶级包名from django.conf只保留django、去掉import ... as ...的别名、把同一模块在多个文件的重复 import 合并为集合。同时会把“项目内自身定义的模块”如models.py、与包名同名的子目录等从结果中剔除避免把自家代码当成第三方依赖——这一点由候选集candidates与 import 集合做差集实现。3. 过滤标准库。剩余的模块名再与内置的 stdlib 清单约 1700 多条标准库模块名做差集os、sys、logging、time、__future__等标准库因此不会出现在 requirements 中。测试 test_get_all_imports() 正是验证了time、logging、curses、__future__等不会被误报。4. 解析包名与版本。剩余的就是候选第三方库随后进入解析环节本地解析get_locally_installed_packages()pipreqs.py遍历sys.path下所有已安装包的top_level.txt建立“包名 → 导出的顶层模块”映射get_import_local()pipreqs.py再按 import 名去匹配。PyPI 查询本地找不到的候选名会请求{pypi_server}{包名}/json获取最新版本号get_imports_info()默认服务器为https://pypi.python.org/pypi/也可用--pypi-server换成私有源。解析失败或网络异常HTTPError的包会被跳过并在日志中提示手动核对。import 名到包名的映射部分 import 名与 PyPI 包名并不一致例如import bs4对应的是beautifulsoup4、import cv2对应opencv-python、import dateutil对应python-dateutil。pipreqs 内置了约 1150 条这样的映射记录见 pipreqs/mapping由get_pkg_names()pipreqs.py在扫描后统一换算找不到映射时则沿用原包名。最后所有依赖按包名小写排序后写入文件这与pip freeze的输出排序习惯保持一致见 pipreqs.py。--use-local与默认模式的差异默认模式先查本地已安装包本地找不到的再上 PyPI 查最新版本。因此即便某个库没装在当前环境也能写出正确依赖。--use-local完全跳过 PyPI 查询只输出当前环境中已安装且与项目 import 匹配的包及其实装版本。适合离线环境或只想基于现有环境生成依赖清单的场景。测试 test_init_local_only() 验证了该模式下只会出现本地安装的包。已存在文件的保护与强制覆盖默认情况下若目标位置默认path/requirements.txt已存在文件pipreqs 会输出requirements.txt already exists, use --force to overwrite it并直接结束不会破坏现有内容。测试 test_init_overwrite() 专门验证了这一点。需要重新生成时加--force即可。为什么不用 pip freeze很多人习惯用pip freeze导出依赖但 pipreqs 与它有本质区别README 明确给出了三点理由pip freeze只会保存你环境中通过pip install安装的包——它反映的是“环境里有什么”而不是“项目需要什么”。pip freeze会保存环境中所有包包括那些当前项目根本没用到、只是恰好装在同一环境里的库尤其是在没有使用virtualenv隔离的情况下。有时你只是需要为一个新项目创建requirements.txt根本不想先安装任何模块。pipreqs 完全基于源码扫描不需要任何包预先安装甚至可以在全新的环境里直接为新项目生成依赖清单。从实现角度看pip freeze 依赖“当前解释器已安装的包”而 pipreqs 依赖“项目源码中的 import 语句 PyPI 元数据”两者信息源完全不同。实践中可以将两者互补pipreqs 负责生成最小化的真实依赖pip freeze可用于核对或做环境快照。典型工作流与注意事项常规生成对一个已有源码目录直接执行pipreqs path得到requirements.txt若目录里已有旧文件先加--force。只预览不落盘用--print把结果打到标准输出确认无误后再正式生成。自定义输出位置用--savepath指定文件名比如把依赖写到requirements-dev.txt。离线环境加--use-local仅依据本机已装包生成。私有 PyPI 源加--pypi-server url指向内部源在受限网络中再配--proxy url。处理大型项目用--ignore忽略node_modules、构建产物等无关目录多个目录用逗号分隔或加--no-follow-links防止跟随符号链接产生意外扫描--ignore-errors可让扫描跳过个别语法错误文件而不中断测试 test_ignore_errors() 验证了出错文件被跳过后其余结果仍正常返回。数据科学 / Notebook 项目加--scan-notebooks让.ipynb中的 import 也参与统计。维护既有 requirements用--diff file审查文件中有哪些依赖项目根本没用到再用--clean file一键清除。几点使用提醒解析出的版本号取自 PyPI 当前最新版本与项目实际开发、验证过的版本可能不一致README 与源码日志均提示“请手动核对最终 requirements.txt避免可能的依赖混淆”见 pipreqs.py.ipynb扫描依赖nbconvert/ipython精简安装时无法使用扫描范围默认只覆盖.py/.pyw开启 notebook 支持后追加.ipynb其他文件类型不会参与。在仓库中继续深入当前仓库提供了完整的源码与测试可供进一步研读核心实现pipreqs/pipreqs.py涵盖参数解析init、扫描get_all_imports、版本解析get_imports_info、get_import_local、对比清理diff、clean等全部逻辑。项目元数据与依赖声明pyproject.toml包含版本号、Python 版本支持范围3.9, 3.14、运行依赖与开发依赖。测试套件tests/test_pipreqs.py覆盖标准库过滤、依赖去重、--ignore、--mode三种动态版本、--diff/--clean、--print、.ipynb扫描、.pyw扫描等场景。测试样例数据如 tests/_data/test.py含别名、相对导入、标准库、不存在模块等典型 import 形态、tests/_data_ignore/test.py验证--ignore行为。内置参考数据import 名到 PyPI 包名的映射表 pipreqs/mapping以及标准库清单 pipreqs/stdlib。赞分享开发工具CLI【免费下载链接】pipreqspipreqs - Generate pip requirements.txt file based on imports of any project. Looking for maintainers to move this project forward.项目地址https://gitcode.com/gh_mirrors/pi/pipreqs点击查看免费下载相关推荐ScreenCloud Windows安装包制作教程WIX工具集打包实战ScreenCloud Windows安装包制作教程WIX工具集打包实战 ScreenCloud 是一款开源的跨平台截图分享工具支持 Windows、Mac桌面应用图像处理Python项目依赖管理神器pipreqs自动生成requirements.txt完整指南Python项目依赖管理神器pipreqs自动生成requirements.txt完整指南 还在为Python项目中的依赖管理而烦恼吗 每次迁移项目都要开发工具CLI终极指南如何用pipreqs自动生成requirements.txt效率提升10倍终极指南如何用pipreqs自动生成requirements.txt效率提升10倍 在Python项目开发中手动管理依赖包并编写requirements开发工具CLI上一篇探秘Nessie一个统一的数据版本控制系统下一篇Frigate NVR基于本地实时目标检测的完整 IP 摄像头 NVR 系统深度解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 pipreqs 使用指南：基于项目 import 自动生成 requirements.txt
开发工具CLI【免费下载链接】pipreqspipreqs - Generate pip requirements.txt file based on imports of any project. Looking for maintainers to move this project forward.项目地址https://gitcode.com/gh_mirrors/pi/pipreqs点击查看免费下载pipreqs 是一款根据项目源码中的 import 语句自动扫描并生成requirements.txt的 Python 命令行工具它不需要你提前安装任何依赖也不需要依赖当前 Python 环境里已有的包列表而是从源码出发逆向推导项目真正用到的第三方库。读完本文你将掌握 pipreqs 的安装方式、全部命令行参数PyPI 解析、本地解析、代理、动态版本号、notebook 扫描等、典型使用流程以及它与pip freeze的本质区别并能结合实际源码理解其底层工作原理。安装 pipreqspipreqs 是一个标准的 PyPI 分发包最简单的方式是直接通过 pip 安装pip install pipreqs安装后会在环境中提供pipreqs命令行入口。项目在 pyproject.toml 中声明了该入口指向pipreqs.pipreqs:main因此安装后可以直接在终端调用。精简安装去掉 Jupyter 支持pipreqs 默认附带对 Jupyter Notebook.ipynb的扫描支持这需要引入nbconvert与ipython等较重依赖见 pyproject.toml 中的nbconvert7.11.0、ipython8.12.3。如果你用不到 notebook 扫描功能可以跳过全部依赖只手动安装两个核心运行库pip install --no-deps pipreqs pip install yarg0.1.9 docopt0.6.2其中yarg用于解析 PyPI 的 JSON 接口源码中通过from yarg import json2package导入见 pipreqs.pydocopt用于按命令行帮助文本解析参数见 pipreqs.py。基本用法pipreqs 的核心用法是在命令行传入项目目录路径它会扫描该目录下所有源码文件中的 import 语句去重、过滤标准库再逐个解析出对应的 PyPI 包名与最新版本号最终写入requirements.txt。Usage: pipreqs [options] [path] Arguments: path The path to the directory containing the application files for which a requirements file should be generated (defaults to the current working directory)path是可选的不传时默认使用当前工作目录对应源码 pipreqs.py 中的os.path.abspath(os.curdir)。一个典型示例$ pipreqs /home/project/location Successfully saved requirements file in /home/project/location/requirements.txt生成的requirements.txt形如wheel0.23.0 Yarg0.1.9 docopt0.6.2默认每条依赖使用精确锁定版本。生成前如果目标目录已存在requirements.txtpipreqs 会给出警告并拒绝覆盖必须显式加--force才会重写对应源码 pipreqs.py。命令行选项详解选项说明--use-local只使用本地已安装包的信息不查询 PyPI--pypi-server url指定自定义 PyPI 服务器地址--proxy url指定代理地址参数会透传给 requests 库也可以通过环境变量HTTP_PROXY/HTTPS_PROXY设置--debug输出调试信息将日志级别切换为 DEBUG--ignore dirs...额外忽略的目录多个目录用逗号分隔--no-follow-links不跟随项目中的符号链接--ignore-errors扫描文件时忽略错误打印堆栈并跳过出错文件--encoding charset指定打开文件时使用的编码默认 utf-8--savepath file将依赖列表保存到指定文件--print将依赖列表输出到标准输出--force覆盖已存在的 requirements.txt--diff file将指定文件中的模块与项目实际 import 做对比报告未使用的模块--clean file清理指定文件移除项目未 import 的模块--mode scheme动态版本号模式compat、gt、no-pin见下文--scan-notebooks同时扫描 Jupyter Notebook 文件.ipynb中的 import代理配置--proxy会把同一个 URL 同时用作 HTTP 与 HTTPS 代理源码 pipreqs.py 构造了{http: url, https: url}传入 requests。也可以不传参数直接在终端导出环境变量$ export HTTP_PROXYhttp://10.10.1.10:3128 $ export HTTPS_PROXYhttps://10.10.1.10:1080动态版本号模式--mode支持三种取值由 dynamic_versioning() 实现compat使用兼容运算符如Flask~1.1.2gt使用大于等于运算符如Flask1.1.2no-pin不锁定版本只写包名如Flask不指定--mode时默认使用精确锁定。如果传入了这三种之外的取值程序会抛出ValueError提示只能使用compat、gt或no-pin见 pipreqs.py。依赖对比与清理--diff file解析指定文件如已有的requirements.txt与当前项目实际 import 集合对比列出“文件中存在但项目里没有 import”的模块由 compare_modules() 与 diff() 实现。--clean file更进一步直接重写指定文件删除其中项目并未 import 的模块行由 clean() 实现。如果文件里没有需要清理的模块会提示Nothing to clean in file。笔记本扫描加上--scan-notebooks后pipreqs 会额外把.ipynb视为扫描对象。底层实现中.ipynb文件会先经 ipynb_2_py() 用nbconvert的PythonExporter转成 Python 文本再进入统一的 AST 解析流程。若环境缺少nbconvert/ipython会抛出NbconvertNotInstalled异常提示先安装这两个库见 pipreqs.py 与 handle_scan_noteboooks()。底层原理从 import 到 requirements.txt理解 pipreqs 的“源码驱动”特性关键在于其核心扫描函数get_all_imports()见 pipreqs.py整个流程分为四个阶段1. AST 解析 import。pipreqs 只扫描.py与.pyw两类文件常量DEFAULT_EXTENSIONS [.py, .pyw]对每个文件用ast.parse()生成语法树再遍历所有ast.Import与ast.ImportFrom节点收集模块名。由于是语法树级解析import xml.etree、from sys import argv、import os.path as test这类写法都能被正确识别。2. 清洗与去重。对收集到的模块名做三件事取顶级包名from django.conf只保留django、去掉import ... as ...的别名、把同一模块在多个文件的重复 import 合并为集合。同时会把“项目内自身定义的模块”如models.py、与包名同名的子目录等从结果中剔除避免把自家代码当成第三方依赖——这一点由候选集candidates与 import 集合做差集实现。3. 过滤标准库。剩余的模块名再与内置的 stdlib 清单约 1700 多条标准库模块名做差集os、sys、logging、time、__future__等标准库因此不会出现在 requirements 中。测试 test_get_all_imports() 正是验证了time、logging、curses、__future__等不会被误报。4. 解析包名与版本。剩余的就是候选第三方库随后进入解析环节本地解析get_locally_installed_packages()pipreqs.py遍历sys.path下所有已安装包的top_level.txt建立“包名 → 导出的顶层模块”映射get_import_local()pipreqs.py再按 import 名去匹配。PyPI 查询本地找不到的候选名会请求{pypi_server}{包名}/json获取最新版本号get_imports_info()默认服务器为https://pypi.python.org/pypi/也可用--pypi-server换成私有源。解析失败或网络异常HTTPError的包会被跳过并在日志中提示手动核对。import 名到包名的映射部分 import 名与 PyPI 包名并不一致例如import bs4对应的是beautifulsoup4、import cv2对应opencv-python、import dateutil对应python-dateutil。pipreqs 内置了约 1150 条这样的映射记录见 pipreqs/mapping由get_pkg_names()pipreqs.py在扫描后统一换算找不到映射时则沿用原包名。最后所有依赖按包名小写排序后写入文件这与pip freeze的输出排序习惯保持一致见 pipreqs.py。--use-local与默认模式的差异默认模式先查本地已安装包本地找不到的再上 PyPI 查最新版本。因此即便某个库没装在当前环境也能写出正确依赖。--use-local完全跳过 PyPI 查询只输出当前环境中已安装且与项目 import 匹配的包及其实装版本。适合离线环境或只想基于现有环境生成依赖清单的场景。测试 test_init_local_only() 验证了该模式下只会出现本地安装的包。已存在文件的保护与强制覆盖默认情况下若目标位置默认path/requirements.txt已存在文件pipreqs 会输出requirements.txt already exists, use --force to overwrite it并直接结束不会破坏现有内容。测试 test_init_overwrite() 专门验证了这一点。需要重新生成时加--force即可。为什么不用 pip freeze很多人习惯用pip freeze导出依赖但 pipreqs 与它有本质区别README 明确给出了三点理由pip freeze只会保存你环境中通过pip install安装的包——它反映的是“环境里有什么”而不是“项目需要什么”。pip freeze会保存环境中所有包包括那些当前项目根本没用到、只是恰好装在同一环境里的库尤其是在没有使用virtualenv隔离的情况下。有时你只是需要为一个新项目创建requirements.txt根本不想先安装任何模块。pipreqs 完全基于源码扫描不需要任何包预先安装甚至可以在全新的环境里直接为新项目生成依赖清单。从实现角度看pip freeze 依赖“当前解释器已安装的包”而 pipreqs 依赖“项目源码中的 import 语句 PyPI 元数据”两者信息源完全不同。实践中可以将两者互补pipreqs 负责生成最小化的真实依赖pip freeze可用于核对或做环境快照。典型工作流与注意事项常规生成对一个已有源码目录直接执行pipreqs path得到requirements.txt若目录里已有旧文件先加--force。只预览不落盘用--print把结果打到标准输出确认无误后再正式生成。自定义输出位置用--savepath指定文件名比如把依赖写到requirements-dev.txt。离线环境加--use-local仅依据本机已装包生成。私有 PyPI 源加--pypi-server url指向内部源在受限网络中再配--proxy url。处理大型项目用--ignore忽略node_modules、构建产物等无关目录多个目录用逗号分隔或加--no-follow-links防止跟随符号链接产生意外扫描--ignore-errors可让扫描跳过个别语法错误文件而不中断测试 test_ignore_errors() 验证了出错文件被跳过后其余结果仍正常返回。数据科学 / Notebook 项目加--scan-notebooks让.ipynb中的 import 也参与统计。维护既有 requirements用--diff file审查文件中有哪些依赖项目根本没用到再用--clean file一键清除。几点使用提醒解析出的版本号取自 PyPI 当前最新版本与项目实际开发、验证过的版本可能不一致README 与源码日志均提示“请手动核对最终 requirements.txt避免可能的依赖混淆”见 pipreqs.py.ipynb扫描依赖nbconvert/ipython精简安装时无法使用扫描范围默认只覆盖.py/.pyw开启 notebook 支持后追加.ipynb其他文件类型不会参与。在仓库中继续深入当前仓库提供了完整的源码与测试可供进一步研读核心实现pipreqs/pipreqs.py涵盖参数解析init、扫描get_all_imports、版本解析get_imports_info、get_import_local、对比清理diff、clean等全部逻辑。项目元数据与依赖声明pyproject.toml包含版本号、Python 版本支持范围3.9, 3.14、运行依赖与开发依赖。测试套件tests/test_pipreqs.py覆盖标准库过滤、依赖去重、--ignore、--mode三种动态版本、--diff/--clean、--print、.ipynb扫描、.pyw扫描等场景。测试样例数据如 tests/_data/test.py含别名、相对导入、标准库、不存在模块等典型 import 形态、tests/_data_ignore/test.py验证--ignore行为。内置参考数据import 名到 PyPI 包名的映射表 pipreqs/mapping以及标准库清单 pipreqs/stdlib。赞分享开发工具CLI【免费下载链接】pipreqspipreqs - Generate pip requirements.txt file based on imports of any project. Looking for maintainers to move this project forward.项目地址https://gitcode.com/gh_mirrors/pi/pipreqs点击查看免费下载相关推荐ScreenCloud Windows安装包制作教程WIX工具集打包实战ScreenCloud Windows安装包制作教程WIX工具集打包实战 ScreenCloud 是一款开源的跨平台截图分享工具支持 Windows、Mac桌面应用图像处理Python项目依赖管理神器pipreqs自动生成requirements.txt完整指南Python项目依赖管理神器pipreqs自动生成requirements.txt完整指南 还在为Python项目中的依赖管理而烦恼吗 每次迁移项目都要开发工具CLI终极指南如何用pipreqs自动生成requirements.txt效率提升10倍终极指南如何用pipreqs自动生成requirements.txt效率提升10倍 在Python项目开发中手动管理依赖包并编写requirements开发工具CLI上一篇探秘Nessie一个统一的数据版本控制系统下一篇Frigate NVR基于本地实时目标检测的完整 IP 摄像头 NVR 系统深度解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考