search

xiaoxx970 / chatgpt-in-terminal

Use ChatGPT in terminal
MIT License
201 stars 27 forks source link

PyPI Release Update #25

Closed Ace-Radom closed 1 year ago

Ace-Radom commented 1 year ago

Done

增加了 ~/VERSION 文件 内部记载目前的版本号 在脚本启动时会分离一个线程向GitHub请求远端的最新版本号同时获取本地版本号 在欢迎行前join 若本地远端版本号一样则不会有任何别的输出 若不同则会提示新版本可用 另外增加了 /version 命令 用于显示取得的本地和远端版本号

这对我来说更多是一个实验性质的功能 我也不知道这样一个功能是否有用或者需要 你怎么看 如果你觉得不太必要的话也没必要merge ~我写的时候也更多是因为好玩才加上这段去调用github的API的~ 如果merge的话记得把远端版本号请求的url改掉 也就是：

https://raw.githubusercontent.com/Ace-Radom/chatgpt-in-terminal/version_ext/VERSION
---> https://raw.githubusercontent.com/xiaoxx970/chatgpt-in-terminal/main/VERSION
xiaoxx970 commented 1 year ago

可以的，我正打算把这个项目弄到pypi，版本号是需要有的。根据pypi项目的规范，本地版本和其他信息放在setup.cfg下

 [metadata]
 name = my_package
 version = 0.1.0

读取的时候用setuptools

from setuptools.config import read_configuration

 # 读取 setup.cfg 文件并获取版本号
 config = read_configuration('setup.cfg')
 version = config['metadata']['version']

就可以了，本地版本的读取可以不用放在线程里。

至于实际的把项目放到pypi，可以之后再慢慢弄

另外得到远程版本的话其实应该使用GitHub的api的，这样更规范一点，不过要用起来的话就得先主分支开始版本管理，我们慢慢想想应该从哪里开始吧

import requests

def check_new_version(user, repo):
    url = f"https://api.github.com/repos/{user}/{repo}/releases"
    response = requests.get(url)

    if response.status_code != 200:
        print("请求失败，请检查用户名和仓库名是否正确。")
        return None

    releases = response.json()

    if not releases:
        print("此项目没有发布版本。")
        return None

    latest_release = releases[0]
    print(f"最新版本：{latest_release['tag_name']}，发布日期：{latest_release['published_at']}")

# 示例
check_new_version("your_username", "your_repository")
Ace-Radom commented 1 year ago

本地版本号移动到 ~/setup.cfg 了 但 ~/VERSION 还保留着以保持目前的功能 等到主分支release发布后改用GitHub API吧 顺便我在测试的时候报了这个警告

image

我没有搞过pypi相关的东西 所以这一类config相关的也是第一次涉及 不太清楚我是不是应该改函数……估计得去再看下文档

xiaoxx970 commented 1 year ago

噢我也是问GPT它告诉我的，看来2021到现在变了挺多

Ace-Radom commented 1 year ago

貌似是变了很多 我在文档里看到也说现在建议用 pyproject.toml 来管理 https://packaging.python.org/en/latest/ 我再翻翻文档改改

但实际上肯定还可以用 setup.py 这样的方式来管理和build 而且不用装别的依赖用python编译 (貌似?) 成whl然后pip本地安装 我觉得会比用新方法方便不少毕竟这个项目也没那么大

xiaoxx970 commented 1 year ago

但实际上肯定还可以用 setup.py 这样的方式来管理和build 而且不用装别的依赖用python编译 (貌似?) 成whl然后pip本地安装 我觉得会比用新方法方便不少毕竟这个项目也没那么大

还能做到编译好后就不需要依赖了？那挺好

Ace-Radom commented 1 year ago

还能做到编译好后就不需要依赖了？那挺好

我不太清楚 但我看隔壁一个项目 (CMDGPT) 的部署流就是如果是从pip直接安装那会自动下载 setup.py 内的所有依赖 然后再安装本体 然后本体就是一个exe (像pip那样的) 安装目录在 /{Python_Install_DIR}/Scripts 换句话说不是不需要依赖 是不需要用户再手动一边 pip install -r requirements.txt 了 然后之后启动就和pip一样不需要再指定python启动了可以直接启动 并且这样的话貌似版本号会直接打包进exe内 用 pkg_resources.get_distribution().version 获取 但我还没测试 (也是GPT教的hh)

但问题也是有的 首先就是项目的配置结构得改 .env 我建议放到用户目录下 也就是 ~/chatgpt-in-terminal/.env 否则可能出现冲突 本地调试可能会变得麻烦一点 但相对来说应该还好 我在这个branch里先做起部署测试了 但是否真的要采纳我觉得要好好斟酌 毕竟这样是在动整个项目结构

Ace-Radom commented 1 year ago

image 芜湖~

Ace-Radom commented 1 year ago

改的东西相当多 我简单说说

目前我觉得要大改的就是聊天记录的保存 别的倒都还好没有改那么多 你可以看下代码再考虑一下

然后本地部署的话脚本如下

python setup.py sdist bdist_wheel
# 按照setup.py打包
pip uninstall chatgpt-in-terminal -y
# 如果已经安装过一次则要先卸载
pip install dist/{build_wheel_output}.whl
# 安装本地包 后面的文件名应该改成实际的wheel文件名

可能还需要更改的地方：

xiaoxx970 commented 1 year ago

好了现在有发布了，https://api.github.com/repos/xiaoxx970/chatgpt-in-terminal/releases 还是空的不知道是不是还要等等看可以看到所有release了，关于新版本检查的话，还可以通过pip命令来判断的（等包发布以后）

import requests
from pkg_resources import parse_version

def check_for_updates(current_version, pypi_package_name):
    url = f"https://pypi.org/pypi/{pypi_package_name}/json"
    try:
        response = requests.get(url)
        response.raise_for_status()
        data = response.json()
        latest_version = data["info"]["version"]
        if parse_version(latest_version) > parse_version(current_version):
            print(f"New version available: {latest_version}")
        else:
            print("You are using the latest version.")
    except requests.RequestException as e:
        print(f"Error checking for updates: {e}")

# Usage
current_version = "0.1.0"  # Replace this with your project's current version
pypi_package_name = "your_package_name"  # Replace this with your package's name on PyPI
check_for_updates(current_version, pypi_package_name)

可能这个才是最稳妥的方法，毕竟GitHub上更新了pypi可能没能马上跟上。然后更新的话我的想法是这样的：

  1. 在程序开始的时候运行一个子线程获取最新版本，如果当前就是最新的话就不做任何事情
  2. 如果pypi的版本更新的话就在 ~/.chatgpt-in-terminal/ 下创建一个 new_version 文件，文件内容可以是json也可以是纯文本，包含最新的版本号还有GitHub release的链接
  3. 这次运行就这样了，不去提示用户更新，因为获取新版本需要时间，等获取到了用户可能已经开始打字了，这时候再往终端输出东西就不太稳妥
  4. 下次运行的时候看目录下有没有 new_version 文件，有的话读取版本号和链接打印到终端提醒用pip命令更新或者查看release日志（甚至可以直接运行一个subprocess帮用户用pip命令更新，待定吧不稳妥）

这样下来就是个更新的流程，也就是说脚本每次启动后要做的两件事：

  1. 查看有没有 new_version 文件，有的话和当前版本对比，如果一样就删除 new_version 文件，不一样就提醒用户
  2. 启动检查新版本的子线程，然后不管它继续后面的事情
xiaoxx970 commented 1 year ago

.env 和 chat.log 将置于 ~/.chatgpt-in-terminal/ 下 这个路径在程序启动时会判断是否被创建 若没有的话会自动建立 若没有找到 .env 的话也会新建一个把 .env.example 内的内容写进去【虽然方法很蠢

是不是可以直接复制文件 .env.example 到 .env 呢

聊天记录的保存路径目前只能保存在 ~/.chatgpt-in-terminal/ 下 我还没把聊天记录保存的逻辑重写 只改了加载时会判断是否是绝对路径 是相对路径的话都默认从 ~/.chatgpt-in-terminal/ 找 这样其实造成了一个问题就是默认路径会变得混乱 我的设想是之后所有保存在 ~/.chatgpt-in-terminal/ 下的聊天记录在程序内指向的时候都在开头加一个类似于 */ 的标识符 然后在程序内加上特判 如果输入是这个标识符开始的路径那么就从 ~/.chatgpt-in-terminal/ 找 否则就正常按启动路径找

日志是应该记录在 ~/.chatgpt-in-terminal/ 下，但是聊天记录就不一定了，其实不用加特判的，直接用户写什么路径就保存什么路径就可以。用户写的相对路径，那就保存到他当前运行命令的目录下，用终端的用户会意识到这个问题的，也不应该保存到 ~/.chatgpt-in-terminal/，不然用户想从当前目录读聊天记录的，结果脚本还去 ~/.chatgpt-in-terminal/ 里找，这就尴尬了

xiaoxx970 commented 1 year ago

版本号的话我还是觉得应该直接写进setup.py，然后用 importlib.metadata 来获取（这是3.8后才有的应该不会太过时），少一个文件还是不错的

from importlib.metadata import version, PackageNotFoundError

def get_package_version(package_name):
    try:
        package_version = version(package_name)
        return package_version
    except PackageNotFoundError:
        print(f"{package_name} not found.")

package_name = "your_package_name"
print(f"{package_name} version: {get_package_version(package_name)}")
xiaoxx970 commented 1 year ago

好了我的目标大概就是这样，要是你有空的话可以慢慢实现下，我的话要周六才会来写了

Ace-Radom commented 1 year ago

可能这个才是最稳妥的方法，毕竟GitHub上更新了pypi可能没能马上跟上。

确实如此 毕竟上了PyPI我也应该不会自行打包本地部署而是直接 pip install --upgrade 了 那么也没有必要去访问GitHub的API直接从PyPI获取好了 但有一个问题我不清楚就是PyPI的API在墙内访问有问题嘛 还是说使用这个工具本来就必须要代理工具所以无所谓 这些我没办法考虑因为我人不在国内 只是一直听国内的人说pip要配置镜像所以有点疑惑

如果pypi的版本更新的话就在 ~/.chatgpt-in-terminal/ 下创建一个 new_version 文件，文件内容可以是json也可以是纯文本，包含最新的版本号还有GitHub release的链接

new_version 的设想我觉得很好 确实毕竟这个项目并不是一个命令行工具而是一个CLI 如果每次开头都要等待新版本检查确实不好 但是否可以像pip那种在退出的时候看一下是否有 new_version 文件呢 我觉得可以考虑考虑【但我觉得必要性不大】

下次运行的时候看目录下有没有 new_version 文件，有的话读取版本号和链接打印到终端提醒用pip命令更新或者查看release日志（甚至可以直接运行一个subprocess帮用户用pip命令更新，待定吧不稳妥）

我觉得也有点不太稳妥 最好的例子就是为什么pip更新必须要 python -m pip install --upgrade pip 而不是直接pip开头 因为如果是python开头那么主进程是python 但pip开头的话主进程就是pip了 pip没法在自己是主进程的同时升级自身 那么在这里也同理 如果能够让python分离一个线程出来运行脚本 然后主线程直接结束支线程继续运行更新 然后再由支线程启动主线程的话倒是可以 但前提是可以实现

是不是可以直接复制文件 .env.example 到 .env 呢

这个是我~偷懒~ 因为 setup.py 里的request文件打包我还是没搞懂 也没有成功过索性就直接写在源码里了~反正也没那么长~ 但我慢点会再去看看有没有什么更好的解决方法

日志是应该记录在 ~/.chatgpt-in-terminal/ 下，但是聊天记录就不一定了，其实不用加特判的，直接用户写什么路径就保存什么路径就可以。用户写的相对路径，那就保存到他当前运行命令的目录下，用终端的用户会意识到这个问题的，也不应该保存到 ~/.chatgpt-in-terminal/，不然用户想从当前目录读聊天记录的，结果脚本还去 ~/.chatgpt-in-terminal/ 里找，这就尴尬了

hm……这个可能就是因为我个人使用方式的问题了 我是直接在win terminal里给他配了一个profile 所以会遇到这类问题

image

如图 他的启动目录要么是配置锁死的脚本所在目录 要么就是 %SystemRoot%\system32 也就是父进程cmd的目录 那么当然解决方法最简单的是更改这个启动目录到一个你平时经常够得着的地方 问题也不大~只是当时没想到~ 但我觉得既然如此的话有必要在readme里提一句 不知道你怎么看 但我现在就不实现我刚才提到的那个设想了

版本号的话我还是觉得应该直接写进setup.py，然后用 importlib.metadata 来获取（这是3.8后才有的应该不会太过时），少一个文件还是不错的

可以的 我一会儿去测试一下 但如果是3.8之后才有的话……会不会还有很多人还在用3.7或者3.6之类的……？(C++开发后遗症 老是遇到环境不支持C++17来问的人 但不管如何我测试完可用后就把 ~/VERSION 删掉了 ~顺便加一下python版本要求~实际上直接用 pkg_resources.get_distribution() 即使删掉 ~/VERSION 也无所谓一样能获取 之前还把版本号放在那里更多是因为不用一直改setup 现在看看也无所谓 所以我目前没有直接改用 importlib.metadata 还是老样子

我今明都可以写写 考试也考完了时间也是有 你周六回来了看下我写了的东西吧

Ace-Radom commented 1 year ago

另外一点就是 因为现在 .env 被移到用户目录下了 更改应该多少有点麻烦 是否要在询问API Key之后直接写入 .env？这样毕竟省去了使用者跑一边用户目录的事 同理我觉得也可以加一些启动命令 类似于 --set-timeout 之类的命令 用来更改 .env 内的值 但我不知道dotenv这个库能不能实现

Ace-Radom commented 1 year ago

开一个~伪~白板

TODO List:

开发log:

Issues:

  1. 在setup中即使将version改为 v0.9.0 后 通过 pkg_resources.get_distribution() 或是 importlib.metadata.version() 仍无法读取版本号开头的v 貌似会自动parse
  2. 若是在后台请求远程版本号 并在得到回复后更改 remote_version 的值 那么是不是有一种很小很小的可能性: 在后台线程更改 remote_version 值的同时用户调用了 /version 命令 我自然知道这种情况几乎不可能出现 但我还是在考虑为 remote_version 加入线程锁
  3. 我认为 new_version 文件其实没有必要删除 当成一个配置文件就行 只需要在每次启动时比对一下 new_version 中的版本和本地包中的版本就行 这个比对并不会耗费多少时间 但可能的问题是：在用户端查找到更新 将更新存入 new_version 中后 在用户端下一次启动前远端的版本号被更新了 那么在用户端下一次启动时 new_version 中的版本号一样时旧的 而且请求最新远端版本 的行为在比对 new_version 内版本和本地版本之后 那么此时显示在屏幕上的所谓“最新版本”其实一样时旧版本 按照当前的逻辑这其实是个挺难解决的问题 我打算在 raise EOFError 后也显示一次新版本提示 然后在下次启动时做好说明这个新版本是上次启动时探测到的 你怎么看
  4. 没有用于更新 .env 的直接方法 dotenv 库并没有提供要更新的话只能手动写入 ~我在考虑改成json yaml不熟悉 但说实话我还是喜欢 .env 这个样式 直观还能加注释还简单 如果是C++的话我可能就手搓解析库了【毕竟当初也写过ini的解析库】但python毕竟没那么熟悉 我再想想还有没有别的办法吧~ 完事了 本质上确实搓了个类似于解析的出来 现在能直接改 .env 了没必要改配置文件格式了
xiaoxx970 commented 1 year ago

在退出的时候看一下是否有 new_version 文件

这个好诶我都没想过，可以在退出的时候检查我觉得

他的启动目录要么是配置锁死的脚本所在目录 要么就是 %SystemRoot%\system32 也就是父进程cmd的目录

脚本是能知道自己被运行的时候所在的目录的，用 os.getcwd()，我没实际去尝试打包后的程序能不能用这个命令，但是肯定是有命令能做到找到当前用户所在目录的

但如果是3.8之后才有的话……会不会还有很多人还在用3.7或者3.6之类的……？

好问题，所以我们要在readme里说明了一定要3.8以上，毕竟现在都出到3.11了，连GPT都知道3.8，所以这个版本要求不过分

另外一点就是 因为现在 .env 被移到用户目录下了 更改应该多少有点麻烦 是否要在询问API Key之后直接写入 .env？这样毕竟省去了使用者跑一边用户目录的事 同理我觉得也可以加一些启动命令 类似于 --set-timeout 之类的命令 用来更改 .env 内的值 但我不知道dotenv这个库能不能实现

这个我也想过，是应该帮用户写key的，修改和查看的命令也需要有，要是dotenv做不到的话就用其他格式比如yaml或者json

在setup中即使将version改为 v0.9.0 后 通过 pkg_resources.get_distribution() 或是 importlib.metadata.version() 仍无法读取版本号开头的v 貌似会自动parse

python的版本号标准是没有字母的，所以这不算大问题，在pypi中的版本号就应该不包含v

若是在后台请求远程版本号 并在得到回复后更改 remote_version 的值 那么是不是有一种很小很小的可能性: 在后台线程更改 remote_version 值的同时用户调用了 /version 命令 我自然知道这种情况几乎不可能出现 但我还是在考虑为 remote_version 加入线程锁

我看到 /version 命令就是读取现在的变量没有发起新的请求，那其实在可以读取版本之前先check_remote_update_thread.join()这样就可以了？而且即便还没完成请求，remote_version 还是None，显示None也是问题不大的

我认为 new_version 文件其实没有必要删除 当成一个配置文件就行 只需要在每次启动时比对一下 new_version 中的版本和本地包中的版本就行 这个比对并不会耗费多少时间

这个确实可以

至于新版本可能是过时的这个问题，我觉得不要在意这么多细节，就是在退出的时候显示tokens统计的时候也提示下用户有新版本就行了，甚至开头的版本判断都没那么有必要了？主要是不要显得烦人就行了

Ace-Radom commented 1 year ago

好问题，所以我们要在readme里说明了一定要3.8以上，毕竟现在都出到3.11了，连GPT都知道3.8，所以这个版本要求不过分

确实 那我就在setup里锁死py版本3.8+了 现在还没改用 importlib.metadata.version() 主要还是因为还需要 parse_version 所以 pkg_resources 库还没法丢掉 但这个库毕竟是setuptools的扩展不是py核心库 兼容性可能会出问题 那么在PyPI上线远端版本不再需要 parse_version 后舍弃掉改用核心库自然最好 【刚刚看到 3.7还有两个月就结束支持了 这个版本要求确实不过分】

image

我看到 /version 命令就是读取现在的变量没有发起新的请求，那其实在可以读取版本之前先check_remote_update_thread.join()这样就可以了？而且即便还没完成请求，remote_version 还是None，显示None也是问题不大的

我觉得不用join 还是用线程锁比较好 因为这个锁只会在 remote_version 读取或更改时候锁住基本不会有大的阻塞 但join不一样 何况如果 /version 先锁的话输出的远端版本一样是None 我觉得目前这样问题不大 不知道你怎么看

这个我也想过，是应该帮用户写key的，修改和查看的命令也需要有，要是dotenv做不到的话就用其他格式比如yaml或者json

好的我去看一下怎么实现

这个确实可以

至于新版本可能是过时的这个问题，我觉得不要在意这么多细节，就是在退出的时候显示tokens统计的时候也提示下用户有新版本就行了，甚至开头的版本判断都没那么有必要了？主要是不要显得烦人就行了

我也觉得开头的没那么必要了 只需要启动一个线程去询问远端版本号就好了 然后在Exit的时候显示一下新版本信息 这么说的话 new_version 的必要性都不大了？毕竟如果开头不用比较的话那么拉取到的最新版本也没必要储存 直接存在变量里就好了 我目前在退出时候写的新版本检查输出差不多这样

image

我觉得这样还不错 你怎么看

xiaoxx970 commented 1 year ago

这个退出信息挺好，而且是的，没必要再用 new_version 文件了毕竟存在变量里就行，又能少一个文件 /version那个用线程锁也可以

xiaoxx970 commented 1 year ago

接下来就剩起名字了，我昨晚想到 GPTerminal ,或者 GPTerm, 命令的话 gpterm 这样简短一点比较好。再想想还有什么其他直观的名字

Ace-Radom commented 1 year ago

接下来就剩起名字了，我昨晚想到 GPTerminal ,或者 GPTerm, 命令的话 gpterm 这样简短一点比较好。再想想还有什么其他直观的名字

我觉得GPTerm这样不错 比较直观也短 但可以再想想会不会还有更好的

Ace-Radom commented 1 year ago

另外我有一个提案：能否把 /tokens /usage /version 三个会输出Panel的命令里的Panel style从 dim 改为默认？ 因为我觉得这些Panel和别的比如 /undo /delete 等命令的输出不同 他们并不是告知用户命令已经被成功执行的提示语 而应该和gpt的回答一样是用户请求的信息 那么我觉得不太应该调暗 不知道你怎么看

Ace-Radom commented 1 year ago

.env 内值更改的核心提炼出来是这些

with open(f"{config_dir}/.env", 'r') as f:
    env_strip = f.read().strip()
env_strlist = env_strip.splitlines()

for config in config_need_to_set:
    for i in range(len(env_strlist)):
        thisline = env_strlist[i]
        if config['tag'] in thisline and thisline.strip().index(config['tag']) == 0:
            env_strlist[i] = f"{config['tag']}={config['data']}"

env_strip = "\n".join(env_strlist)
with open(f"{config_dir}/.env", 'w') as f:
    f.write(env_strip)

我的思路是 既然 dotenv 库不提供 .env 内值的更改 那么要更改内部的值就只能通过文件读写实现了 而 .env 内的配置项是严格按行分开的 不可能有两个配置项写在同一行里 那么就用 .splitlines() 把整个 .env 的每一行分别拆进一个list 之后的查找tag就按照每一行 (也就是list里的每一项) 来查 随后有一个特判：必须判断这个tag出现的这一行是否是一行注释 因为在你给的 .env.example 里确实出现了这个情况 https://github.com/xiaoxx970/chatgpt-in-terminal/blob/cd2a56650ee9739205f06f87f23b9c353e77a358/.env.example#L7-L9 ~要是没L8这行注释我早就写完了~ 判断是否是注释的方法就是在去除首尾空格后判断这个tag的起始位置是否是0 (如果是注释的话tag的最前起始位置也应该是1) 只有在满足这个条件下 才会覆盖该行的数据

别的就没什么了 重新将list转为str然后覆写

Ace-Radom commented 1 year ago

又优化了一下 把实际修改 .env 值的功能单独分了一个函数出去 这样在主程序启动询问api key之后更改 .env 里的设置方便一点 就是我这两个commit里每次修改 .env 都用了两次with open 应该有更好的方法吧……？我不是很清楚

我目前能做的大概都做完了 那个把 .env.example 打包的东西我还是没搞懂 你如果绝对最好还是打包的话要不你再看看

xiaoxx970 commented 1 year ago

要是没L8这行注释我早就写完了 判断是否是注释的方法就是在去除首尾空格后判断这个tag的起始位置是否是0 (如果是注释的话tag的最前起始位置也应该是1) 只有在满足这个条件下 才会覆盖该行的数据

啊有没有可能可以先跳过所有#开头的行

if line.startwith("#"):
    continue
xiaoxx970 commented 1 year ago

其实要是没有很优雅的写配置到.env的方法的话，用config.json或者config.yaml可能更好。一开始之所以用.env是因为看到别的项目这样用，但是它的好处其实就是在于部署到vercel这样的平台的时候可以通过环境变量来配置项目而不用修改代码，但是，我们一个在本地终端运行的项目，好像并享受不到这个好处，要说有就是可以先export api key到shell变量然后运行chay.py，但是还是写配置文件方便一点

Ace-Radom commented 1 year ago

啊有没有可能可以先跳过所有#开头的行

啊？ 啊行吧是我昨天晚上脑子抽了（

其实要是没有很优雅的写配置到.env的方法的话，用config.json或者config.yaml可能更好。一开始之所以用.env是因为看到别的项目这样用，但是它的好处其实就是在于部署到vercel这样的平台的时候可以通过环境变量来配置项目而不用修改代码，但是，我们一个在本地终端运行的项目，好像并享受不到这个好处，要说有就是可以先export api key到shell变量然后运行chay.py，但是还是写配置文件方便一点

也确实是这样 我刚开始是觉得继续沿用 .env 会省去用户类似于重写配置文件之类的问题 但现在看来必须要重新设置的也就一个api key 这个看你怎么想吧 如果你觉得改json或者yaml更加好的话那么你就把我写的那段删掉就好 我今天国内到凌晨之前都没时间你如果有空的话可以改改

xiaoxx970 commented 1 year ago

这个看你怎么想吧 如果你觉得改json或者yaml更加好的话那么你就把我写的那段删掉就好 我今天国内到凌晨之前都没时间你如果有空的话可以改改

还看成你凌晨之前到国内😂我现在来改了

xiaoxx970 commented 1 year ago

另外我有一个提案：能否把 /tokens /usage /version 三个会输出Panel的命令里的Panel style从 dim 改为默认？ 因为我觉得这些Panel和别的比如 /undo /delete 等命令的输出不同 他们并不是告知用户命令已经被成功执行的提示语 而应该和gpt的回答一样是用户请求的信息 那么我觉得不太应该调暗 不知道你怎么看

这个确实，是展示信息而不是提示，所以是应该不dim

xiaoxx970 commented 1 year ago

接下来就剩起名字了，我昨晚想到 GPTerminal ,或者 GPTerm, 命令的话 gpterm 这样简短一点比较好。再想想还有什么其他直观的名字

我觉得GPTerm这样不错 比较直观也短 但可以再想想会不会还有更好的

没想到啊这都能被注册了 https://pypi.org/project/gpterm/

不过刚才我也想了一下用 gpt-term 也可以，缩太短了反而还有点看不懂

Ace-Radom commented 1 year ago

不过刚才我也想了一下用 gpt-term 也可以，缩太短了反而还有点看不懂

也可以 这样也挺好

还有区分包启动还是脚本启动是怎么区分出来的……是靠这个嘛

global local_version
try:
    local_version = parse_version(get_distribution('gpt-term').version)
except DistributionNotFound:
    local_version = 'unknown'
log.debug(f"Local version: {str(local_version)}")
# get local version from pkg resource

如果是这个的话那可能会是脚本启动时get到安装过的包版本 但是我觉得这种细节问题没必要过多考虑了就提一下 毕竟这么弄完真的会本地用脚本形式启动的估计也就开发者了

然后我把启动log改了一下 (脚本名) 然后在之前预留好的pypi远端版本请求的程序段里也改了下包名 你可以看一下

xiaoxx970 commented 1 year ago

你说的有道理欸，要是在本地装了pip包的情况下，这个判断方法就失效了。我还想的是可能有用户需要直接运行脚本而不是安装包呢，如果不费力能保留这种可能性的话我还是想保留一下。好像用name == "main"这样是可以判断的，等我一会试试

xiaoxx970 commented 1 year ago

手动发布了一下，名称算是占住了 https://pypi.org/project/gpt-term/ 接下来就是

Ace-Radom commented 1 year ago

我有看到GitHub的workflow是被创建在我那个fork出去的分支仓库里的 我不太了解所以问一下这个在使用上真的没问题嘛 我主要是有点担心这样我后期在仓库里做点东西的时候会不会出问题 还是说这个不会影响

xiaoxx970 commented 1 year ago

我有看到GitHub的workflow是被创建在我那个fork出去的分支仓库里的 我不太了解所以问一下这个在使用上真的没问题嘛 我主要是有点担心这样我后期在仓库里做点东西的时候会不会出问题 还是说这个不会影响

我也看到了它同时在你的action里也运行了，没影响的因为真的发布到pypi还需要配置密钥到环境变量才可以。后面我会设置成只有新的release才会运行workflow，那样只会在我的repo里运行了

Ace-Radom commented 1 year ago

我也看到了它同时在你的action里也运行了，没影响的因为真的发布到pypi还需要配置密钥到环境变量才可以。后面我会设置成只有新的release才会运行workflow，那样只会在我的repo里运行了

好的 那我到时候再考虑这个分支在merge后要不要删吧

啊顺便我启动了一个将这个项目用C/C++重构的计划 cGPTerm 你如果感兴趣的话可以去看看……？虽然我现在一头雾水就是了C的CLI是真的不太会玩（雾 好多模块都要手搓的样子 要么没有要么功能太复杂根本用不到

xiaoxx970 commented 1 year ago

我也看到了它同时在你的action里也运行了，没影响的因为真的发布到pypi还需要配置密钥到环境变量才可以。后面我会设置成只有新的release才会运行workflow，那样只会在我的repo里运行了

好的 那我到时候再考虑这个分支在merge后要不要删吧

啊顺便我启动了一个将这个项目用C/C++重构的计划 cGPTerm 你如果感兴趣的话可以去看看……？虽然我现在一头雾水就是了C的CLI是真的不太会玩（雾 好多模块都要手搓的样子 要么没有要么功能太复杂根本用不到

可以啊很高级，c我就不太会了，只有在大学学过点皮毛，要是真弄出来了那肯定运行的飞快。有个叫nuitka的python编译器可以把python代码转换成c++，不知道对你有没有用

Ace-Radom commented 1 year ago

可以啊很高级，c我就不太会了，只有在大学学过点皮毛，要是真弄出来了那肯定运行的飞快。有个叫nuitka的python编译器可以把python代码转换成c++，不知道对你有没有用

可以的我一会儿去看一下 刚刚看了下整个项目要用到的模块 感觉做出来难度还行 难在流式回复和CLI结合这一块 md-parser那是直接放弃了 但gpt的存在还是弥补了知识上的短板应该说 总而言之把他当成一个C单人项目练手我觉得不错（毕竟我也不觉得以我的CLI开发实力可以把他做到和原版一样好用 不得不说 在用C做这类项目的时候就开始怀念python的模块了 虽然我在写python的时候老是怀念C的运行速度（

xiaoxx970 commented 1 year ago

完事咯去主分支看看workflow有没有正常

Ace-Radom commented 1 year ago

发布喽 已经下载下来玩了 win terminal的配置问题确实是我多虑了 设置好启动目录的话使用没有问题 ……害真发布了 挺好的（

xiaoxx970 commented 1 year ago

是呀人生第一次发布pypi包，也辛苦你啦，要是没有你天天推进这个功能的话我估计会拖延很久

Ace-Radom commented 1 year ago

是呀人生第一次发布pypi包，也辛苦你啦，要是没有你天天推进这个功能的话我估计会拖延很久

哈哈没事 我也是因为有这方面的需求才一直推进的xD 但最近估计会集中课余时间去搓我那个重构项目了【目前看了看可能到最后是纯C实现】可能会把我原来在想的类似于撤销上一次回答重新询问之类的功能放一放 毕竟C的话一堆轮子都要自己造 现成的要么不符合要求要么没有这功能 像流式回答之类的实现相比py来说是真的复杂太多了 相当于我要自己写类似于prompt_toolkit rich requests模块的好多内容 还有一个极轻量化的线程安全log库已经写完了（哭 我甚至都开始考虑c调py了 我知道怎么调用但估计不太适合 ncurses的对接属实不太友好

总之等我那阶段性成果出来之后我再回来考虑一下有没有什么可以加的东西（ 目前是觉得如果可以一键redo挺好的 但貌似没那么大需要毕竟有undo

xiaoxx970 commented 1 year ago

你的c项目确实复杂多了，没有这么多现成的轮子，加油吧

Ace-Radom commented 1 year ago

你的c项目确实复杂多了，没有这么多现成的轮子，加油吧

一方面是如此 另一方面是调用极其复杂 这几天看的英语文本量估计赶上我学校里半年的量（ 但愿能在两个月内写完 否则我就没有apikey测试了（