确保python cli匹配insuert.txt中设置的版本

发布于 2025-02-07 02:19:01 字数 354 浏览 0 评论 0原文

我正在为 https://pretextbook.org/ 作者,我正在共同开发CLI。当作者运行Prineext New时,我们为其新项目生成样板文件,包括与CLI的当前版本相匹配的unignts.txt。如果作者更新其CLI软件包,则项目的源文件可能不再与更新的软件包兼容。是否有一种规范的方法来解析unigess.txt文件并打印出警告,即使用的CLI版本与unignts.txt中的版本不匹配?

I'm co-developing a CLI for https://pretextbook.org/ authors. When an author runs pretext new we generate boilerplate files for their new project, including a requirements.txt that matches the current version of the CLI. If the author updates their CLI package, their project's source files may no longer be compatible with the updated package. Is there a canonical way to parse a requirements.txt file and print out a warning that the CLI version being used does not match the version set in requirements.txt?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

套路撩心 2025-02-14 02:19:01

如果我想解析 pip 之类的需求文件,我会使用 pip-Requirements-parser ,因为 pip 本身不能轻易用作库,而 pip-requirements-parser 声称与<<<<<< em> pip 。

另一方面,我认为您根本不需要。如果预计用户可以编辑需求文件,那么您将无法真正从这些版本中推断出任何内容。

考虑以下问题:

  1. 新项目是使用 pripext v1.2.3
  2. sumption.txt包含pertext == 1.2.3
  3. 用户编辑文件以制作它的pripext&gt; = 1.2.3
  4. 用户更新 pertext to v2.3.4
  5. 项目源不再与 pertext ,但CLI版本匹配需求.txt规范。

因此,您需要另一个解决方案,例如专用.pretext_project_version文件,因此您可以合理地期望用户不将项目要求和兼容的CLI版本混淆。这也将为自己简化项目版本,因为您必须仅在不兼容的更改上撞到该版本,而不是编码逻辑(例如)project v 1.0与1.5和2.0兼容,而不是2.2”

If I wanted to parse requirements file like pip, I'd use pip-requirements-parser, since pip itself can't easily be used as a library, and pip-requirements-parser claims to be as close to pip as possible.

On another hand, I don't think you need that at all. If user is expected to edit requirements file, then you can't really deduce anything from these versions.

Consider this:

  1. New project is created using pretext v1.2.3
  2. requirements.txt contains pretext==1.2.3
  3. User edits the file to make it pretext>=1.2.3
  4. User updates pretext to v2.3.4
  5. Project source is no longer compatible with pretext, but CLI version matches requirements.txt specification.

Hence you need another solution, like a dedicated .pretext_project_version file, so you can reasonably expect user to not confuse project requirements and compatible CLI version. This would also simplify project versioning for yourself, because you'll have to bump that version only on incompatible changes, rather than encode logic like "project v 1.0 is compatible with 1.5 and 2.0, but not 2.2"

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文