且构网

分享程序员开发的那些事...
且构网 - 分享程序员编程开发的那些事

如何管理您的 Perl 应用程序开发、构建和部署?

更新时间:2023-09-13 19:53:34

关于这个我可以写很多

  1. 库的控制 - 我只用我想要的模块创建我自己的 CPAN 版本.App::Cpan 的最新版本具有多项功能,例如 -j 选项来加载一次性配置,以帮助解决这个问题.一旦你有了它,你就可以将它分发到一个拇指驱动器或 CD 上,其中包含所有模块、CPAN.pm 配置以及你需要的一切.只需稍加编程,您就可以创建一个 run_me 脚本来实现这一切.

  1. Control of libraries - I create my own versions of CPAN with just the modules I want. The latest versions of App::Cpan has several features, such as the -j option to load one-time configurations, to help with this. Once you have this, you can distribute it on a thumb-drive or CD which has all of the modules, the CPAN.pm configuration, and everything else you need. With a little programming you create a run_me script that make it all happen.

Makefile/Build 集成 - 我不集成 Makefile.那是通往灾难的道路.相反,我使用***应用程序模块进行集成测试,该模块也会自动测试其所有依赖项.-t 切换到 cpan 命令对于测试当前工作目录中的模块很有用:

Makefile/Build integration - I don't integrate the Makefiles. That's the road to disaster. Instead, I do integration testing with the top-level application module, which automatically tests all of its dependencies too. The -t switch to the cpan command is useful to test the module in the current working directory:

cpan -t .

您也可以使用各种交互测试框架.您将 PERL5LIB 设置为空(硬编码的 @INC 目录中只有核心模块),因此 cpan 必须从头开始安装所有内容.

There are various intergation testing frameworks that you can use too. You set PERL5LIB to something empty (with only have the core modules in the hard-coded @INC directories) so cpan has to install everything from scratch.

  1. 版本控制友好——你使用什么并不重要.大多数东西都有某种导出功能,您可以在没有源代码控制的情况下获得所有东西.Git 非常好,因为它在正常情况下只有最少的污染.

  1. Version control friendly - it doesn't much matter what you use. Most things have some sort of export where you can get everything without the source control stuff. Git is very nice because it only has a minimum of pollution in the normal cases.

跨平台 - 我提到的所有内容都可以在 Windows 和 Unix 上正常运行.

Cross platform - everything I've mentioned works just fine on Windows and Unix.

单个 Perl 安装 - 这部分更棘手,我认为您走错了路.任何时候多个东西必须依赖同一个 perl,有人会为其他人搞砸.我绝对建议不要使用系统 Perl 进行应用程序开发,以免扰乱系统的运行.至少,每个应用程序都应将所有非核心模块安装到自己的目录中,以免与其他应用程序竞争.

Single Perl install - this part is more tricky, and I think you're going in the wrong way. Any time multiple things have to depend on the same perl, someone is going to mess it up for the others. I definitely recommend not using the system Perl for application development just so you don't mess up the operation of the system. At the minimum, every application should install all non-core modules into their own directories so they don't compete with other applications.

易于启动 - 这只是一个简单的编程问题.

Easy start up - that's just a simple matter of programming.

奖励:我不使用 Module::Starter.这是错误的方法,因为您必须依赖 Module::Starter 认为您应该做什么.我使用 Distribution::Cooker 它只是获取模板工具包模板的目录并将它们处理为给他们你的分发目录.你可以做任何你喜欢的事情.如何获得初始模板取决于您.

BONUS: I don't use Module::Starter. It's the wrong way to go since you have to depend what Module::Starter thinks you should do. I use Distribution::Cooker which simply takes a directory of Template Toolkit templates and processes them to give them your distribution directory. You can do anything that you like. How you get the initial templates is up to you.