Re: [go-nuts] Re: Best practices for file scoping
Use Ginkgo -- great test runner and the Gomega test matcher is awesome too. Works out of the box also with straight up go test. That was my solution back in 2015, and is still my solution todaystill writing golang. On Mon, May 25, 2020 at 1:52 PM wrote: > Me too. Running into the same exact situation. > > On Saturday, May 9, 2015 at 9:44:06 PM UTC-7, Davis Ford wrote: >> >> I know this is an ancient thread, but I thought I'd see if anyone has any >> clever tricks for getting around this with unit tests. >> >> I have a package that has a handful of files. In other languages, >> file-scope variables are very useful for tests, as I often declare a list >> of of variables at the top of the test (e.g. the entity under test, as well >> as several other dependencies it needs that I can inject into it to mock >> its behavior, etc.) This is becoming problematic in golang. Many times >> the list of these variables across files is similar -- similar >> dependencies, etc., and I need to new them up for the test, but now they >> collide across test files. >> >> I'm looking at the following possibilities: >> >> * Move the declaration into every test function so they scoped at the >> function, but this just repeats code and becomes very verbose. >> * Put them all in a struct and reference them as fields hanging off the >> global test struct declared in each test file but this is tedious and makes >> the code less clear (IMO) >> * Just rename them to similar but different names in each test file, >> (this is what the OP was talking about doing) >> * Refactor all the code to try to work around this -- untenable >> >> On Thursday, November 18, 2010 at 11:56:38 AM UTC-5, Russ Cox wrote: >>> >>> We spent a long time on this and decided that in Go >>> file boundaries are never relevant, nor is the order of >>> top-level declarations. This makes it nearly trivial to >>> move code between files as makes sense for organization. >>> (The one exception is imports, but making imports work >>> "at a distance" seemed even worse.) >>> >>> I have found myself in the situation you are in on >>> occasion, and I always end up doing one of these: >>> >>> 1. Use a per-package logger variable. >>>If this is just for debugging, that's often fine. >>> >>> 2. Identify what the semantic split of the logging >>>is, and use that in the name. For example, if >>>your package is readers and writers and that's >>>how the logging breaks down, then readLogger >>>and writeLogger seem reasonable. >>> >>> Russ >>> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/s9ShMsCLuXI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/a90b8b93-b9d8-4fc1-a666-63b355ebdef0%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/a90b8b93-b9d8-4fc1-a666-63b355ebdef0%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAHyzJDPM7AF1pao%2BfhUJahWDzQz2%3Djgbt_2yRrGn_MCPZnz6CQ%40mail.gmail.com.
[go-nuts] Re: mgo r2015.12.06 is out
Just in case anyone else lands here, Mongo doesn't support mixed mode replica set with 2.6.x and 3.2.x -- I learned that the hard way, adding a new 3.2 member to the replica set to work on upgrading the nodes. I had to remove that node, and build all new 3.0 nodes; now I'm in the process of moving the 3.0 nodes to 3.4.1 On Thursday, December 17, 2015 at 11:52:48 AM UTC-5, Darko Luketic wrote: > > Would you recommend staying on 3.0 or is it safe to upgrade to 3.2 in a > single mongos cluster with 3 rs? > aka "is it safe to upgrade to 3.2"? > > "There are still a couple of upstream issues" sounds like "sit it out" > > On Monday, December 7, 2015 at 3:38:00 AM UTC+1, Gustavo Niemeyer wrote: >> >> ... >> - Several tweaks in the test suite to make MongoDB 3.2 happy. There are >> still a couple of upstream issues that need handling before this is fully >> sorted. >> ... >> gustavo @ http://niemeyer.net >> > -- 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.
Re: [go-nuts] tool to print dependency graph of /vendor libs
Daniel, fwiw I couldn't get govendor list to work in my environment.
Sam, thanks a lot of that snippet. I also had some trouble running that,
but I was able to reverse engineer the important parts out to generate a
one-liner that worked for me.
go list -f '{{ range .Imports }}{{printf "\t%q -> %q;\n" $.ImportPath
.}}{{end}}' $(go list -f '{{join .Deps " "}}' YOURPACKAGE) YOURPACKAGE
When I tried the script as is (found a similar script here
<https://github.com/NeoHuang/scripts/blob/master/getGoDepends.sh>), it
errors out with
template: main:1: unexpected "\\" in operand
If you know a quick resolution to that, I'd love to get it working with
digraph and graphviz, as well.
On Fri, Sep 2, 2016 at 2:51 PM, Sam Whited wrote:
> On Fri, Sep 2, 2016 at 1:20 PM, Davis Ford wrote:
> > Does anyone know of a tool that can analyze dependencies and print a
> graph,
> > specifically as it relates to golang vendor'd libraries. I'm using 1.7
> and
> > most tools don't seem to be able to produce results on a project that is
> > using vendor'd dependencies.
>
> Something like the following chunk of Bash would work (you could tweak
> the Go list invocation to just do vendored deps probably) if you have
> graphviz installed (I can't remember where I got this, appologies if
> I'm cribbing a script out of someones presentation without proper
> attribution):
>
> % ( echo "digraph G {"; \
> % go list -f '{{range .Imports}}{{printf "\t%q -> %q;\n" \
> % $.ImportPath .}}{{end}}' \
> % $(go list -f '{{join .Deps " "}}' YOURPACKAGE) YOURPACKAGE;
> \
> % echo "}";
> % ) | dot -Tsvg -o $@
>
> —Sam
>
>
> --
> Sam Whited
> pub 4096R/54083AE104EA7AD3
>
--
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.
[go-nuts] tool to print dependency graph of /vendor libs
Hi, Does anyone know of a tool that can analyze dependencies and print a graph, specifically as it relates to golang vendor'd libraries. I'm using 1.7 and most tools don't seem to be able to produce results on a project that is using vendor'd dependencies. Tools I've tried: - https://github.com/shurcooL/cmd/tree/master/goimporters - https://github.com/shurcooL/cmd/tree/master/goimportgraph It generates a nice svg graph for my src/ but isn't including the source w/in the src/vendor directory -- 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.
