relative imports and duplicate includes

Poul-Henning Kamp phk at
Tue Nov 17 15:58:56 CET 2015

In message <CABaBnj70CMv-rT8Y7rayM+Kd5xQQQbMRXo6a+o0PCoFuU_knpA at>
, Kacper Wysocki writes:

>How does the "just like $PATH" behavior solve the original problem of
>"I wanted to release complete, self contained vcl packages"?

So, this is one of those procedural things...

It might have been better to open a discussion with the problem
you're trying to solve, rather than throw out a patch that does
something with only passing mention of the problem and no
analysis of it :-)

>An instance of the problem I have out there is
>a multi-site varnish has vcl snippets site1/main.vcl which includes
>site1/foo.vcl and site1/bar.vcl and site2/main.vcl which includes
>site2/foo.vcl site2/zool/baz.vcl. Today these includes have to either
>be absolute, or relative to vcl_dir.

Now we're talking...

See below...

>> What if one is:
>>         import "foo";
>> and the other is:
>>         import "foo" from /somewhere/";
>> Isn't that a problem ?
>I don't know. In either case you're assuming something about what the
>user wants. I would like to do
>import "foo";
>include "some/other/vcl";

Yes, but if some/other/vcl expects vmod_foo to be one thing and another
already imported something different under that name, you are screwed
and will get *really* weird error messages.

The current "include" facility is 100% textual and you can do stuff

	if (include condition.vcl;) { ... }

Which is incredibly powerful and 100% unstructured.

Both of the two issues you raise actually sound like something
entirely different is needed, some kind of "local namespaces",
so that the "include foo_lib.vcl" can have its own vmods and includes,
which do not affect or spill out over the rest.

Maybe what we really need is VCL libraries:

	library geoip geoip.vcl [from "path"];


	sub vcl_recv {

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

More information about the varnish-dev mailing list