perl - 我应该从模块文件导出配置还是从另一个文件解析？

我的脚本需要用户提供密码，登录和其他自定义设置。截至目前，我在perl脚本中对其进行了硬编码。这有点麻烦，因为我经常在其中工作并将其提交回公共远程git存储库。每次我提交更改时，我都必须记住使用个人信息和自定义设置取消设置变量。

所以我想知道是否应该创建一个模块来包装这些变量，然后在脚本中使用模块，或者我应该创建一个文件（json，xml，text等），然后在我的脚本上解析这个文件获取个人信息和设置。使用该脚本的人对编程并不陌生，因此它不像有组织的文件会使最终用户端更容易。由于我是一个菜鸟，我不知道为什么我可以在使用模块时解析文件，这就是为什么我倾向于使用该模块。这是一种不好的做法吗？

一种运行良好的策略是创建模板/示例配置文件，并仅将该文件置于版本控制之下。然后，您可以使用修订控制系统为该任务提供的任何构造来设置要忽略的“真实”配置文件。（以下是Subversion，Git和Mercurial中的操作方法。）

例如，您可以签入 app.sample.conf ，然后在结帐/克隆您的仓库时，其他人会将其复制到 app.conf 。

通常的解决方案是在版本控制中放置带有虚拟值的示例配置，并进行设置，以便版本控制系统忽略真实的配置文件，这样它也不会意外地被检入。

或者，您可以使用twelve-factor solution并从环境变量而不是文件中获取配置值。

另一种方法是在第一次运行时向用户询问信用，将它们保存到git仓库中永远不需要的配置文件中。第一次运行后，用户可以编辑此配置文件以更改详细信息。但是，在git repo中使用默认值的示例文件将允许用户自己手动设置一个文件。

use warnings;
use strict;

use Config::Tiny;

my $file = 'myapp.ini';
my $config = Config::Tiny->new;

my ($un, $pw);

if (! -e $file){

    print "what's your username?: ";
    $config->{user}{un} = <>;

    print "what's your password?: ";
    $config->{user}{pw} = <>;

    $config->write($file);
}

$config = $config->read($file);

$un = $config->{user}{un};
$pw = $config->{user}{pw};

print "un: $un, pw: $pw\n";

我认为代码和数据之间的区别较小，更多的是关于项目的特定块是否可变。对于像CSS和HTML这样的声明性语言来说，这是最清楚的，与JavaScript相比，我们很难说我们是在讨论代码还是数据，因为它只是因为程序性而明显是“代码”

即使可变性也很难确定，因为它取决于项目的特定视图。在开发期间，一切都是可变的，而在部署之后，除了应用程序使用的文档和配置数据之外，一切都是固定的。甚至可以说配置比app的文档“更少”可变

网页的HTML，CSS和JavaScript模型也有助于显示另一个明显的区别：目的。三位一体分别对应于网页的内容，表示和功能，我认为我们可以从中汲取指导原则“将各层保持在一起“，无论同一性是否存在于我们尚未想到的可变性，目的或其他方面

无论如何，我认为配置数据几乎在所有方面都与项目的任何其他部分不同。它既是代码又是数据，它可以被认为是最初只是另一个应用程序文档，直到几年过去而没有被更改，它变得不可变，或者实际上是如此，并且实际上是代码的一部分

我想在这里混合使用的另一件事是，我相信一个应用程序应该工作，并且某些是合理的，有用的，没有任何配置。显而易见的方法是使应用程序启动时加载和使用的默认配置发现自己没有自定义配置数据。此时它将拉入默认配置并开始相应地运行，当应用程序退出时将当前的steup写入实时配置

我的建议是编写一个属于项目一部分的默认配置文件，并让应用程序仅在真空启动时才使用它。此后，将维护一个可以根据需要编辑的实时配置文件。默认和实时配置应采用相同的格式，因为我们不想编写Perl模块来存储我们的配置数据，所以它们应该是XML，YAML，JSON或其他类型。默认配置将是项目的一部分，实时配置将被视为一个非常特殊的应用程序文档

我应该从模块文件导出配置还是从另一个文件解析？

4 个答案: