The Coro situation

Since my recent participation at the QA Hackathon I have become aware that rather more people than I expected do not know the specifics of this situation. Fewer than I expected have heard of it at all, even, although there appears to be some general awareness at the “something happened with that” level at least.

However, the situation is being used to characterise Marc Lehmann whenever his name comes up (and it comes up rather more often than I would expect or consider necessary).

To give a clear picture of the facts and to avoid repeating that exercise every time I have a related conversation, here is an outline of where we are and how we got here.

(Thanks to Andreas König, Graham Knop, and Peter Rabbitson for proofreading drafts of this article and verifying the stated facts.)

A very stupid, over-clever scoping-based importing trick

In some code I’m working on, I use a module which exposes a whole bunch of package variables as part of its public interface. It does not export them, however. I could refer to them directly by prefixing them all with Some::Module::, but that would be ugly and verbose. It’s also unsafe – the vars stricture will not help you catch typos if you use fully qualified names.

The obvious solution would be to emulate what exporting does:

Perl 6

Wow, you people.

Making local::lib real easy to use

In bash, at least.

Just paste this (on your command line or into .bashrc or wherever else you want):

perl-lib() { eval "`perl -M'local::lib @ARGV' - "$@" 0<&-`" ; }

Then you can just say things like this:

$ perl-lib ~/locallib/foo
$ perl-lib --deactivate ~/locallib/bar
$ perl-lib --deactivate-all

… instead of having to type stuff like this:

$ eval "`perl -Mlocal::lib - --deactivate ~/locallib/bar`"

… or even, as you would have had to in old versions of local::lib, this awfulness:

$ eval "`perl -Mlocal::lib=--deactivate,$HOME/locallib/bar`"

Note that the shell function will work irrespective of local::lib version.

Update: I originally posted this with a 1<&- redirect in the function, which closes STDOUT. What I actually wanted to do was close STDIN, of course.

Developing virtualhost-aware PSGI applications: Plack::Middleware::MockProxyFrontend

Let’s say you work on a team that runs a web content management system for various different customers. It is hosted at, but each customer’s public content is published on a different domain, which is determined by a setting in the interface, which they can change at will. When a customer is logged into they see links to their public content in various places, and some of the public content has “edit this”-type links back into All of this runs as a single PSGI application. A not unfamiliar scenario, presumably.

How do you spin up a development server where you can test this?