relative imports and duplicate includes

[Poul-Henning Kamp]

--------
In message <CABaBnj70CMv-rT8Y7rayM+Kd5xQQQbMRXo6a+o0PCoFuU_knpA at mail.gmail.com>
, 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/libvmod_foo.so";
>>
>> 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
like:

	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 {
		geoip.recv_stuff();
	}


-- 
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.