Our approach was to identify function calls that consume a Context (indicated by a call to context.TODO in the function body) and function calls that provide a Context (such as RPC and HTTP handlers). Then we use the guru callgraph tool to find all call paths from context providers to context consumers. These are the call paths that need to have a context plumbed through them.
Starting from a context consumer, we can work upward to the context provider, adding a context parameter to reach intervening function signature. Replace context.TODO in the consumer function body with the new ctx parameter, then update all the places that call the consumer to pass context.TODO. Now we have a new set of context consumers. Repeat until you reach the context providers (if you reach main or a Test function, pass context.Background instead). This works OK for static function calls but gets messy for dynamic calls. If you need to add a context parameter to an interface method, now you have to update all implementations of that method, too (guru can find these for you). And if that interface is outside your control (like io.Writer), you cannot change its signature, so you have to pass the context some other way (such as via the method receiver). This gets yet more complicated if you cannot make atomic changes to all callers of your functions, because callers may be in other repositories. In this case, you must do an incremental refactoring in multiple steps: each change to a function signature involves adding a new function that has the context parameter, then changing all existing calls to use the new function, while preventing new calls to the old function, so that you can finally delete it. Inside Google, we ended up not needing to build all this: Context was introduced early enough that Go users could plumb it manually where needed. I think a context plumbing tool could still be interesting and useful to other Go users. I'd love to see someone build it! S On Tue, May 9, 2017 at 10:54 AM <mhhc...@gmail.com> wrote: > > I've done a limited form of this using awk ;-) > > if you have a minute, > > can you tell more about what limited you > in your attempts and which trade made you stop (guessing), > if any ? > > Do you still think it be awesome ? > Or have you made your mind to an opposite position ? > if so, For which reasons? > > My tool is very poor, consider it as on going, a place for inspiration to > get started from absolutely no idea to lets get a dirty prototype. > not sure yet how long is going to be the road, still digging :) > > > On Tuesday, May 9, 2017 at 4:25:46 PM UTC+2, Sameer Ajmani wrote: > >> The eg tool can execute simple refactoring steps, but automating context >> plumbing through a chain of calls is an open problem. Alan Donovan put some >> thought into this a few years ago, and I've done a limited form of this >> using awk ;-) >> > On Tue, May 9, 2017 at 6:10 AM <mhh...@gmail.com> wrote: >> > I want something similar too. >>> >>> Automatic and smart insertion of context args in a chain of calls. >>> >>> Methods signature updates are easy, but how to appropriately insert >>> context check in the ast ? >>> I m not sure yet. >>> >>> >>> >The difficulty here seems to differentiate intra package calls from >>> calls to standard/3rd party libraries which shouldn't be having new param. >>> >>> That does not sound too difficult, from the pkg identifier, lookup for >>> the import path, for every import path, exists in GOROOT ? >>> >>> Please put updates here anything you want to share. >>> >>> At that moment i m using this package to help me with ast, >>> https://github.com/mh-cbon/astutil >>> >>> might be a start even though it needs refactoring. >>> >>> >>> On Monday, May 8, 2017 at 1:03:52 AM UTC+2, meir fischer wrote: >>>> >>>> I'm adding tracing to an existing code base with many packages and it >>>> seems the best way to have context's passed around is to just have every >>>> method take a context.Context. >>>> >>>> Is there any tooling for converting a code base/package to have: >>>> (a) context.Context as the first parameter in each function - ctx >>>> context.Context >>>> (b) for any function that has changed, have its callers (within that >>>> package) pass ctx as the first arg >>>> >>>> The difficulty here seems to differentiate intra package calls from >>>> calls to standard/3rd party libraries which shouldn't be having new param. >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> >> To unsubscribe from this group and stop receiving emails from it, send an >>> email to golang-nuts...@googlegroups.com. >> >> >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
