Re: Test-time dependencies.
A. Pagaltzis [EMAIL PROTECTED] writes: That seems wrong. Every module you install contains lists of dependencies, one list for runtime, one for build-time. The CPAN shell won’t ask questions about missing dependencies, that is true. But why does that matter? You have the dependency lists anyway. Let's try to work out an example. You have a build system, and a series of production systems. The production systems need module Foo::Simple. Module Foo::Simple requires Foo::Heavy at run-time, and Test::Ridiculous at build time. A mere build (not install, just build) of Foo::Simple causes Foo::Heavy and Test::Ridiculous to be installed on the build system[1]. After install of Foo::Simple, three new modules got added to the build system. If Test::Ridiculous were not installed, I could chase down the perl installation to find out what files were added[2], and distribute these to the production systems. Now I have to manually weed out the files that are not needed for production. As I said, it increases the maintenance load. -- Johan [1] So if you decide not to use Foo::Heavy after all, you can't just throw away the build results since the build system has already been permanently modified. [2] Module::Build at least provides a target fakeinstall that will provide this information. Unfortunately, most modules are still MakeMaker based.
Re: Test-time dependencies.
On Aug 4, 2006, at 8:04 AM, Johan Vromans wrote: Ken Williams [EMAIL PROTECTED] writes: My intention when I added 'build_requires' to Module::Build was not to let people avoid downloading building those dependencies, but rather to indicate that there was no runtime dependency, ... For this to function properly, the 'build_requires' modules (and their respecitve dependencies!) should all be downloaded and installed in a temporary location (e.g., blib) and not be installed permanently. That's really up to the user to decide. They may wish to install them permanently just so they save themselves the bother of building installing them again next time. -Ken
Re: Test-time dependencies.
On Aug 4, 2006, at 10:21 AM, Johan Vromans wrote: As already mentioned by other people in other threads, if you prepare install kits for many systems, you would not want to install all the build-time requirements, only the run-time requirements. If the install kit is essentially a binary distribution that won't build test, just essentially copy files, then yeah. Don't include build-time dependencies in it. That would indeed be a waste. -Ken
Re: Test-time dependencies.
On Aug 5, 2006, at 4:27 AM, Johan Vromans wrote: If Test::Ridiculous were not installed, I could chase down the perl installation to find out what files were added[2], and distribute these to the production systems. Now I have to manually weed out the files that are not needed for production. [...] [2] Module::Build at least provides a target fakeinstall that will provide this information. Unfortunately, most modules are still MakeMaker based. A trivial patch to MakeMaker would let you do this with MakeMaker too, since it's just a pass-through to ExtUtils::Install that's doing the real work. Essentially the Makefile would need this change: --- Makefile~ 2006-08-03 22:10:19.0 -0500 +++ Makefile2006-08-05 12:45:26.0 -0500 @@ -215,7 +215,8 @@ ECHO_N = echo -n UNINST = 0 VERBINST = 0 -MOD_INSTALL = $(PERLRUN) -MExtUtils::Install -e 'install([EMAIL PROTECTED], '\''$(VERBINST)'\'', 0, '\''$(UNINST)'\'');' +NONONO = 0 +MOD_INSTALL = $(PERLRUN) -MExtUtils::Install -e 'install([EMAIL PROTECTED], '\''$(VERBINST)'\'', $(NONONO), '\''$(UNINST)'\'');' DOC_INSTALL = $(PERLRUN) -MExtUtils::Command::MM -e perllocal_install UNINSTALL = $(PERLRUN) -MExtUtils::Command::MM -e uninstall WARN_IF_OLD_PACKLIST = $(PERLRUN) -MExtUtils::Command::MM -e warn_if_old_packlist and then you'd run: % make pure_install NONONO=1 That wouldn't show you the man page installs, but in an environment like the one you're describing maybe you don't care about man pages anyway? -Ken
Re: Indexing for AI-Prolog-0.735_01?
BTW, you might want to add a see also in the AI::Prolog docs for the SWI-Prolog wrapper? -Ken On Aug 4, 2006, at 7:22 AM, Joshua ben Jore wrote: PAUSE says to send problems to modules@perl.org but perl.org's web page says that's a closed list?! So now this is two problems. One is why PAUSE isn't indexing AI-Prolog and the other is that the published contact doesn't accept messages from authors. Or doesn't *seem* to anyway.
Re: Test-time dependencies.
On Sat, Aug 05, 2006 at 11:27:09AM +0200, Johan Vromans wrote: A. Pagaltzis [EMAIL PROTECTED] writes: That seems wrong. Every module you install contains lists of dependencies, one list for runtime, one for build-time. The CPAN shell won?t ask questions about missing dependencies, that is true. But why does that matter? You have the dependency lists anyway. Let's try to work out an example. You have a build system, and a series of production systems. The production systems need module Foo::Simple. Module Foo::Simple requires Foo::Heavy at run-time, and Test::Ridiculous at build time. A mere build (not install, just build) of Foo::Simple causes Foo::Heavy and Test::Ridiculous to be installed on the build system[1]. After install of Foo::Simple, three new modules got added to the build system. If Test::Ridiculous were not installed, I could chase down the perl installation to find out what files were added[2], and distribute these to the production systems. Now I have to manually weed out the files that are not needed for production. As I said, it increases the maintenance load. This is true if you're installing all modules required in one block. Whereas I believe that the counter arguments come from people who are considering the case of packaging up each module in turn, and marking that package as only depending on the packages (modules) that it stated as run-time requirements, basing that dependency information on the metadata from the modules (instead of what got installed) Nicholas Clark
Re: Indexing for AI-Prolog-0.735_01?
- Original Message From: Ken Williams [EMAIL PROTECTED] BTW, you might want to add a see also in the AI::Prolog docs for the SWI-Prolog wrapper? Probably a good idea. It's recommended in AI::Prolog::Article, but that's about it. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Indexing for AI-Prolog-0.735_01?
On 8/5/06, Ovid [EMAIL PROTECTED] wrote: - Original Message From: Ken Williams [EMAIL PROTECTED] BTW, you might want to add a see also in the AI::Prolog docs for the SWI-Prolog wrapper? Probably a good idea. It's recommended in AI::Prolog::Article, but that's about it. Already applied to my source. Good suggestion. Thanks. Josh
Re: Test-time dependencies.
Johan Vromans wrote: Ken Williams [EMAIL PROTECTED] writes: My intention when I added 'build_requires' to Module::Build was not to let people avoid downloading building those dependencies, but rather to indicate that there was no runtime dependency, ... For this to function properly, the 'build_requires' modules (and their respecitve dependencies!) should all be downloaded and installed in a temporary location (e.g., blib) and not be installed permanently. This is what Module::Install does when you use 'auto_include'. What I've done for recent modules is to bundle Test::Depends by making it the only build_requires line. Then, from the test scripts I can just; use Test::Depends qw(Some::Module), Other::Module = [ @import_args ]; Of course it means that the test suite doesn't get run fully, but I think the output makes that obvious enough. Sam.
