考虑到pkg_mkindex已被弃用，如何管理Tcl包？

我很惊讶地看到，pkg_mkindex已被弃用（）甚至是危险的（）

现在，“弃用”的意思是“已经被一种新的更好的方法所取代，旧的方法不应该再用于新的项目”

然而，我得到的唯一替代建议是手动创建pkgIndex.tcl文件，在我看来，这并不是包创建方面的进步

---

因此，有经验的Tcl开发人员面临一个问题：如果pkg_mkindex不再使用，那么您如何管理软件包？

针对Tcl 9讨论了一个改进的解决方案。（请注意，它并没有被正式弃用。）

有些人想反对它，这也是因为它使用了一种相当幼稚的方法（这并不总是一件坏事），还有一部分是因为现在的库需要的不仅仅是整理要正确安装的

source

文件

对于业余级别的包管理来说，它仍然很有用：只要您为简单的Tcl脚本编制索引，并且避免为调用的目录编制索引，它就可以完成这项工作

（如果您能够编写比

pkg_mkIndex

更复杂的库，那么提供手写索引文件是一件轻而易举的事。但可能仍有更新的工具可用。）

ETA：我的个人解决方案（可能会有变化，我每隔几个月就修改一次设置）是将我经常编辑的库文件（大多数）放在我的工作目录的姊妹目录中。在每个工作目录中，我都有scriptlet，它们可以运行测试套件、动态创建session.vim文件并启动gVim，以及修订控制我的文件。所有这些scriptlet都源于一个小型scriptlet，它为库目录编制索引并将其添加到

auto\u path

。库文件只是.tcl文件，其中包含

包提供的
。我将“完成”的少数库重写为模块，并复制到我的
C:\Tcl\lib\tcl8\8.6
目录中

文档：，
对于大多数软件包作者来说，在开始编写软件包时只运行一次并不成问题。但是它生成的脚本（在
pkgIndex.tcl
中）非常简单，您可以通过调整该脚本来更好地满足自己的实际需求

幸运的是，如果您使用的是Tcl 8.5或更高版本，您可以使用
apply
来简化很多事情。这意味着您可以像这样生成脚本：

### Read this as if it is:
#### package ifneeded $pkg $version [list apply {dir $thescript} $dir]
package ifneeded MyFunkyPackage 1.2.3 [list apply {dir {
    # Work out the right binary library name
    switch $tcl_platform(platform) {
        windows { set lib MFP123.DLL }
        default { set lib libMFP.1.2.3[info sharedlibextension] }
    }
    load [file join $dir $lib] MFP
    # Source a bunch of scripts with their encodings forced to UTF-8
    foreach script [glob -directory $dir MFP*.tcl] {
        source -encoding utf-8 $script
    }
}} $dir]

好的，这是一个非常奇特的包定义脚本，但是用任何其他方法都会很尴尬——用双引号字符串构造脚本会很痛苦，而且可能也很容易出错——但在这里很简单，因为您有局部变量、结构化编程构造和工作。（你也可以在
配置过程中生成正确的东西，假设你遵循TEA模型，但这需要你乐于使用autoconf，这肯定不是所有人都可以使用的…
对于单文件包，8.5中已经引入了Tcl模块，它不需要任何pkgIndex.tcl文件。@schlenk：很好。模块管理虽然简单，但需要进一步简化。大家都同意，模块的管理还不够完善，而且缺少公共开放存储库（除了ActiveState茶壶）也有点令人遗憾。但至少它不像python包装那样是火车失事，每隔几个月就会改变一次。一个主要的不足之处是对包和模块的依赖关系管理。@user1934428:嗯，数据不足。从应用程序中调用
pkg_mkIndex
本身不是问题，只要不索引调用
pkg_mkIndex
的脚本所在的目录（这只是一个无限递归问题）。为项目树中的每个目录编制索引真的有用吗？为了从中受益，您需要将这些目录放在库路径中。（可能我没有正确理解你。）添加了我自己的设置以进行比较。
pkgIndex.tcl
脚本中的
dir
不是全局变量；脚本在本地上下文中进行评估。