diff --git a/.gitignore b/.gitignore index 3012170..67cd2f5 100644 --- a/.gitignore +++ b/.gitignore @@ -1,3 +1,4 @@ anthropic-agent-skills/ __pycache__/ .venv/ +test-cache/ \ No newline at end of file diff --git a/statements/1.md b/statements/1.md index adeb0b9..d90a98d 100644 --- a/statements/1.md +++ b/statements/1.md @@ -1,9 +1,4 @@ 1. 首先阅读 @statements/optimize.md,还有 @README.md 并根据其指引了解跟aide env有关的所有信息 -2. 我想对aide env的一些行为和参数进行调整,但是我暂时没有很好的思路关于具体的参数命名和数据格式应该如何设计 -3. 我想做的调整可以参考 @statements/example-1.md ,注意: - 1. proc是旧的命名,现已确认更名为aide - 2. 里面的所有内容仅能做大意参考,不要被参考内容中出现的子命令名、参数名、参数数据形式、数据文件名等所限制, - -你是一位拥有丰富经验的资深软件工程师、系统架构师、人体工程学设计师 - -我希望你从参考文档example-1中提取大意,深度思考,全面分析,全力发挥你的专业能力和创造力,引导我对aide env进行重新设计和开发 \ No newline at end of file +2. 我想对aide env的环境模块进行扩展, +3. 支持通过aide命令而非直接编辑配置文件来设置环境配置数据,在设置时命令应该集成对参数合法性的自动检验(例如启用了aide未支持的不存在的模块,比如fortran、cobol),通过命令操作的方式来限制对配置文件编辑的自由度和实现自动检验,避免配置文件数据格式错误 +3. 完成模块扩展和设置命令后在test-cache/目录下为创建一个aide-env-test目录,然后在aide-env-test目录下的子目录中创建各种项目demo,比如rust、flutter、react,并完成相应的配置文件设置,和环境检测 diff --git a/statements/2.md b/statements/2.md deleted file mode 100644 index dad581b..0000000 --- a/statements/2.md +++ /dev/null @@ -1,16 +0,0 @@ -1. 用--modules -2. 扁平结构 -3. 作为独立模块默认启用(因为有可能后续项目稳定后会把所有程序编译为无需额外环境依赖的二进制可执行文件,甚至是使用rust重写程序) -4. 参数用逗号分隔 - -我的新想法: - -1. 弃用check,仅保留ensure, - - 因为不论是有明确的配置文件指定了具体环境模块配置的情况, - - 或者是单独使用模块参数忽略掉配置是否启用, - - 都说明有明确的对指定模块的使用意图, - - 我希望只要执行了就默认为预期是目标环境可用, - - 所以仅保留ensure,若检测到不可用就自动尝试修复,修复成功后可用正常输出反馈告知LLM环境可用即可 -2. 但是使用list时依然显示其模块能力情况,有些模块可能没办法支持ensure, -3. 只有使用--all选项时,不进行ensure操作,仅检测, - - 使用all时对所有已启用的模块仅执行check操作,报告其可用性 diff --git a/statements/3.md b/statements/3.md deleted file mode 100644 index 09847ec..0000000 --- a/statements/3.md +++ /dev/null @@ -1,10 +0,0 @@ -1. 默认all的范围是所有配置文件中已配置为启用的模块 - - 若环境配置文件中没有配置启用列表,则输出警告,然后对所有aid env支持的可用模块进行检测(即使环境配置文件中没有任何相关配置) - - 若环境配置文件中设置了启用列表,想要对所有模块进行检测就必须先用list获取支持的模型的信息,然后用指定模块列表参数执行检测 -2. 若模块ensure失败,或是仅支持check无法ensure却检测到环境不可用 - - 如果该模块是环境配置文件中指定了启用的模块,输出错误,应停下并报告用户需要解决环境问题 - - 如果是没有在启用列表中的,不论是all参数还是指定模块参数触发的,都只输出警告信息 -3. 使用指定模块参数时,不需要考虑是否配置启用,都执行即可(不过输出的是警告还是错误取决于是否启用) - - 所以环境检测模块要考虑到仅有自己的模块名可知的情况,真实配置不可知全靠检测, - - 比如gcc、java、python、flutter、android这样的,看命令是否可用,还有一些相关的环境变量是否已正确配置即可 - - 但如果是py的虚拟环境这种必须指定虚拟环境目录路径的,nodejs这种要先在工作目录(有些项目中需要运行npm但不在项目根目录而是在某个子目录下,此时没有具体目录路径无法检测)做了npm install有了node_modules才能正常运行的,在没有具体配置数据(指该模块独立配置数据例如[env.venv]而非该模块是否启用)但指定了其模块进行check/ensure时,应输出警告然后不执行检测等任何其他该模块行为, diff --git a/statements/example-1.md b/statements/example-1.md deleted file mode 100644 index 54e7917..0000000 --- a/statements/example-1.md +++ /dev/null @@ -1,55 +0,0 @@ -proc environment manager - -## 说明 - -`proc`是一个已经被用户正确安装的程序,可以像`ls`、`cd`、`cat`,`curl`等常用命令一样通过`proc`这个命令名直接随时调用而无需关心其安装路径和程序配置, - -proc是一套针对性设计用于专业步骤流程的程序系统的访问入口, - -可通过`proc`访问其一系列子程序,例如现在将要具体学习的`proc env`,`env`子项专用于处理项目开发时的开发环境情况问题, - -## 行为与用例 - -> 下方代码片段是用空行分隔的多组命令调用示例,每一段注释后直到下一个空行前的一条或多条shell命令是一组,同一组的命令是等效的(通常较短的命令是其他长命令的参数缺省形式), - -```bash -# 对于已启用的项目(python、jdk、gcc、cmake、cargo、rustc、uv、nodejs等)检测其环境的可用性及版本,由默认配置或工作目录下的默认环境配置文件决定启用哪些项目的检测 -proc env -proc env check -proc env check --all -proc env check --all --env-config ./env-config.toml -# 这一组(也包括下一组`proc env show`)中的`--env-config`选项需要一个文件路径参数用于指定环境配置文件,其默认值是工作目录下的`./env-config.toml` - -# 列出所有支持的环境模块并显示: -# 1.当前配置下该环境检测模块是否启用 -# 2.该模块支持的操作(有些模块可能仅支持check而不支持ensure操作) -proc env show -proc env show --all -proc env show --all --env-config ./env-config.toml - -# 支持的参数选项同上,运行所有已启用的环境模块检测其环境的可用性及版本,当目标环境不可用时尝试按既定程序修复环境,仅当所有修复都失败时输出失败消息 -proc env ensure - -# 运行指定的环境模块检测其环境的可用性及版本,且不论其是否已在环境配置中启用 -proc env check --spec ['python'] -proc env check --spec ['java','rust','uv'] -# 这一组中的`--spec`选项需要一个字符串列表参数(即使只有一项),支持的选项可通过`proc env show`获取 - -# 运行指定的环境模块检测其环境的可用性及版本,且不论其是否已在环境配置中启用,当目标环境不可用时尝试按既定程序修复环境,仅当所有修复都失败时输出失败消息 -proc env ensure --spec ['python'] -proc env ensure --spec ['java','rust'] -``` - -## IO约定与示例 - -- env子项仅支持[行为与用例](#行为与用例)中所示的参数选项,不支持动态输入其他参数值 -- 输出前缀: - - 成功:✓ - - 警告:⚠ - - 失败:✗ - -### 输出示例 - -``` -✓ 虚拟环境可用: /home/user/.local/pro-process-program/.venv/bin/python -``` \ No newline at end of file