确保python cli匹配insuert.txt中设置的版本
我正在为 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 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
如果我想解析 pip 之类的需求文件,我会使用 pip-Requirements-parser ,因为 pip 本身不能轻易用作库,而 pip-requirements-parser 声称与<<<<<< em> pip 。
另一方面,我认为您根本不需要。如果预计用户可以编辑需求文件,那么您将无法真正从这些版本中推断出任何内容。
考虑以下问题:
sumption.txt
包含pertext == 1.2.3
pripext&gt; = 1.2.3
需求.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:
requirements.txt
containspretext==1.2.3
pretext>=1.2.3
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"