Was Perl in the runtime closure before?

@7c6f434c No, it is new dependency.
Does this commit need some change? (e.g. add withPerlModule)

Then maybe create a way (like overriding perl argument to null or something) to build without perl? Nginx sounds like something useful on closure-size-conscious VMs and also small cross-compilation targets where Perl might not be reliable yet.

Right, got it.
Then should perl be opt-in or opt-out?

I would prefer opt-in unless a specific feature/set of features implemented as Perl modules and planned for packaging sound useful enough.

I understand :)
Any other problem?

I am not sure if there is a cheap example of a perl module to add as a NixOS test for Nginx or not. (Or maybe it is a part of your larger Perl strategy and I will see it in a week…)

I don't have some perl module suitable for NixOS test since perl_module support is just needed for my private module (single file)...

FYI the following code can be used to run a perl module.

commonHttpConfig = ''
      ...
      perl_modules ${ nginx }/lib/perl5;
      perl_modules ${ makePerlPath [ HTTPDate ] };
      perl_modules ${ makePerlPath [ PHPSerialization ] };
      perl_modules ${ makePerlPath [ URI ] };
      perl_modules ${ ./perl_modules };
      perl_require my_private_module.pm;
      ...
'';
(...).locations."= /test".extraConfig = ''perl my_private_module::handler;'';

Maybe add perl = null at the toplevel then.

@7c6f434c Could you check new commit?

@7c6f434c Thanks!