将样式文件一同打包进模板之中？

[fky2015]

Context

从 V1 升级到 V2 以后，BIThesis 的样式内容被隐藏到了 *.cls 文件中，并通过 CTAN 进行发布。
在模板中，我们通过 \documentclass[]{<CLASSES_FILE_NAME>} 的方式引入，并影响全局效果。

通常情况下，这样减小了样式修改对模板本身的影响——用户只需要通过 LaTeX 包管理器升级宏集即可,不需要修改自己的文件。

但是随之而来会有如下问题：

1. 从 CTAN 发布到进入发行版，通常会有几周的时间。对于紧急更新来说不太能接受。
2. 用户在更新依赖这件事情上缺少积极性。
3. 用户有时候会有想针对某些样式进行小改动的需求。

因此我们需要重新权衡版本发布的方式

Possible Solutions

1. 维持现状，并在文档中说明如何找到样式文件并在项目中修改。
2. 回滚到 V1。（非常不建议，这样我们需要同时维护多份样式）
3. 每次打包模板的时候，让样式文件存放在模板的同一个目录下：通过\documentclass[]{./<CLASSES_FILE_NAME>}的方式使用。（但这样同样让用户更新样式变得困难了）

欢迎发表你的看法。

[atxy-blip]

怎么样提供更新

提供一些我的经验……

从 CTAN 发布到进入发行版，通常会有几周的时间。

事实上没有那么久。上传 CTAN 后一天内就能得到维护组回复，通过的话就会安装到主站服务器上，再等一天（待各个镜像站拉取到新版文件）后网站上会发布通知，这个时候已经能通过 tlmgr 进行更新。另一方面，由于 MikTeX 那边只有一位猛人维护，相对会不及时一点。

对于紧急更新来说不太能接受

什么样的更新算是紧急呢？格式审查失败，需要一天内退回修改吗？这个时候甚至来不及推送到仓库，由社区提供的临时补丁往往更有效。

让样式文件存放在模板的同一个目录下：通过 \documentclass[]{./<CLASSES_FILE_NAME>} 的方式使用

这里有问题。编译时会优先搜索工作目录内的文件，所以说如果当前文件夹下有一个 bithesis.cls，那就会用这个，不必指定 ./。要验证的话，不妨在 .log 文件看看载入的是哪个版本。

那么，我提供的方案是这样：

• 有临时需要的同学直接从仓库的 .dtx 文件解包，这是开发版
• Release 压缩包内附带 .cls 文件，解压就能编译，也能上传 Overleaf 等在线编辑网站，这是正式版
• 每次 Release 后及时上传 CTAN

如果用户需要升级，把工作目录下的 .cls 文件删了，换成新版或者从 tlmgr 更新即可。

这也带来了一点小要求：

• 在仓库中维护一份 CHANGELOG 记录项目变化
• 保持接口稳定，对于用户层面尽量只做增量更新，提高前后版本兼容性

更新的必要性

如果用户没有用出当前版本的问题，当然没必要更新；当他们需要更新时，自然会来求助，那就引导到写好的文档。

---

进一步的建议

用户有时候会有想针对某些样式进行小改动的需求

让我们回想一下原则：内容与样式分离。对于用户，.cls 文件或许应当被妥善隐藏起来。那怎么做修改呢？由模板提供选项，具体而言就是键值对接口，譬如常用的 \ctexset、\hypersetup 等等。能修改的地方是可以穷举的，日后发现新的改动点，加一个选项就好，在用户层面的学习成本比较低。

我看了一下你们的模板，目前用 \newcommand 来输入个人信息，可以说是一种不保险（也不友善）的方式。斗胆推荐一下 l3keys2e 和 LaTeX3 接口 中的 l3keys 一节，虽然说学习曲线很陡峭，但熟悉以后确实挺方便的。至于实现出来效果怎样，可以看看 fduthesis，以及我那个（逃

（还是很羡慕有学校官方支持的模板啊）

更新：发现问题很大，将包含绘制过程的 .tex 文件直接分发给用户并不合适，封面、摘要等等的样式都应该直接、完全由 .cls 文件提供。

[fky2015]

十分感谢！您的宝贵经验不仅给我们提供了改进的方向，也让我们感受到了前进的动力。

事实上没有那么久。

受教了。这里暴露了我经常不更新包的问题:)。

什么样的更新算是紧急呢？

一般是毕业季提交论文那段时间。最坏的情况是，有必须要修改的内容要推送给用户。确实，这样走 Release 会更快一些。

那么，我提供的方案是这样：

• 有临时需要的同学直接从仓库的 .dtx 文件解包，这是开发版
• Release 压缩包内附带 .cls 文件，解压就能编译，也能上传 Overleaf 等在线编辑网站，这是正式版>
• 每次 Release 后及时上传 CTAN

所以说你其实更支持“在 Release 的模板中附加 .cls”这个选项？但是如果结合你其他建议，其实直接依赖发行版的包效果也完全相同了。不过确实，这样的优势是能够直接上传 Overleaf。

---

斗胆推荐一下 l3keys2e 和 LaTeX3 接口 中的 l3keys 一节

十分感谢，之前有过想法使用类似的库来提供更好的配置方式，但是一直偷懒了。

可能这也跟我们下面这个问题相关：

将包含绘制过程的 .tex 文件直接分发给用户并不合适，封面、摘要等等的样式都应该直接、完全由 .cls 文件提供。

比如像是封面这种 .tex 文件，里面混杂着样式、数据、甚至图片；同时也有很多 corner case 没有处理（比如某行内容过长以后的换行问题）。因此我迟迟不敢直接放到 .cls 中（受限于我个人编写样式的水平）。然后作为负面影响，也导致使用 key-value 这种配置接口的计划一再推迟。

但是这确实是需要直面的问题，从长期来看是我们需要解决的。

再次表示感谢！

[atxy-blip]

所以说你其实更支持“在 Release 的模板中附加 .cls 这个选项？

直接依赖发行版的包效果也完全相同

请原谅我说得太碎了。我建议的实际上是个掀桌子的方案，把目前发布包里的 abstract.tex 等等任何跟格式有关的东西都塞进 .cls，发布的时候提供一个完全跟格式分离的空白配置，就像这个一样：njuthesis-user-v0.16.0.zip。Realease 的包实际上是提供一个项目参考，发布到 CTAN 的最终目的是用户可以像标准的 article 文档类一样，新建一个 .tex 文件就能直接开始写作。

很自然会产生一个问题：这样一来，怎么支持多种类型，比如开题报告、课程论文呢？那就提供不同控制选项，或者利用 docstrip 的代码复用功能（ %<class> ）分出多个文档类。

迟迟不敢直接放到 .cls 中

请不必担心，塞进去以后所有的变更都会发生在 .cls 文件，用户层面是封装好的 \maketitle 或者类似的接口，迭代的阻力会小很多。

[fky2015]

最新的版本已经按照此方式实现。