thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Deering <tom.deer...@workiva.com>
Subject Re: Code Generation With Distributed, Versioned Dependencies
Date Mon, 09 Nov 2015 20:36:50 GMT
Sorry if I wasn't clear. It sounds like you understand the problem I'm
asking about.

> When you are generating code with "external dependencies", how are you
"including" those files if you don't have them locally?
Exactly :) That's what I was hoping to answer. It would be great to be able
to generate code for a service without needing every service to have its
own local copy of the full transitive closure of included Thrift files.
Local copies of dependencies can get stale, may tempt you to edit them, etc.

> Perhaps you could give a more concrete example of what you mean.
Good idea. Consider Maven for Java projects, wherein a pom.xml file
describes a project's dependencies and from where they can be retrieved.
You *do* need a local copy of these in order to compile or run your
program. But you certainly wouldn't manually fetch the forward closure of
dependencies and check them all into your project. Instead this happens
lazily as-needed at build time. It would be nice if Thrift code generation
worked similarly. My question was whether such a thing exists, or if the
standard "solution" is to make a copy of your dependencies and keep them
around locally with your own service definition.

On Mon, Nov 9, 2015 at 1:50 PM, BCG <bgould@hushmail.com> wrote:

> On 11/9/2015 at 1:32 PM, "Tom Deering" <tom.deering@workiva.com> wrote:
> >
> >Thanks, Ben. I understand the "be liberal in what you accept"
> >philosophy
> >that allows mismatched versions of a Thrift client and server to
> >talk
> >(regardless of whether that's a good idea
> ><https://techblog.workiva.com/tech-blog/postel%E2%80%99s-cycle>).
> >It seems
> >that you're suggesting, therefore, that pinning specific versions
> >of
> >external Thrift dependencies is unnecessary because due to
> >interoperability.
> >
> >However, I don't see that this solves the problem of generating
> >code from
> >Thrift files that have external includes (unless I keep a copy of
> >them
> >locally like you suggest).
>
> Maybe I'm not understanding your problem...
>
> I'm assuming by "external dependencies" you mean structs, enums, unions,
> typedefs, exceptions, or parent services contained is some other thrift
> file than the one you are compiling against... please correct me if I am
> wrong
>
> When you are generating code with "external dependencies", how are you
> "including" those files if you don't have them locally?  AFAIK when you
> invoke the Thrift compiler you're operating on local files.  So when you
> generate either your clients or your servers in whatever language, you're
> operating on some local file.
>
> >I was hoping for a solution that lets
> >each
> >service be the source of truth for the single copy of its own
> >Thrift
> >definition instead of keeping copies within dependent services.
> >
>
> Perhaps you could give a more concrete example of what you mean... you
> said this problem is solved in most programming languages already... maybe
> framing it in terms of another language that has solved this already would
> be helpful
>
> Thanks
>
> Ben
>
>


-- 
Tom Deering, PhD | (563) 249-9277 | Software Engineer, Workiva

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message