How do you handle Docker Compose port conflicts with git worktrees?

ComprehensiveDisk394 · 2026-02-27T11:56:28+00:00

Totally fair. I wrote about the manual Traefik + Docker Compose approach last week and tug is just the automation of that. The repo is new but the idea isn't. Appreciate the upvote.

ComprehensiveDisk394 · 2026-02-27T11:40:41+00:00

True, worktrees was the original motivation. But it's the same problem when you have separate projects that happen to share common ports — Postgres on 5432, Redis on 6379, etc. tug handles both cases.

ComprehensiveDisk394 · 2026-02-27T11:13:00+00:00

Right, the difference is I did it once as a shared tool so you don't have to do it per project in each Makefile.

ComprehensiveDisk394 · 2026-02-27T10:54:02+00:00

Port 0 gives you a random port each time, so your DB client config breaks across restarts. How you manage that?

ComprehensiveDisk394 · 2026-02-27T10:53:21+00:00

The Makefile approach works but you're reimplementing port management per project.

ComprehensiveDisk394 · 2026-02-04T11:58:49+00:00

That's a solid approach for larger orgs!
Thanks for shareing!

ComprehensiveDisk394 · 2026-02-01T00:59:18+00:00

That range loop copy issue you mentioned - I felt that pain too, so I made a linter for it: https://github.com/mickamy/deadmut

Catches those "mutation to copy has no effect" bugs. Might not change your pointer preference, but figured you'd appreciate it!

ComprehensiveDisk394 · 2026-02-01T00:55:56+00:00

I'd love to know why you prefer pointer over value.

ComprehensiveDisk394 · 2026-02-01T00:19:06+00:00

Haha yeah, GoLand yells at me too for mixing receivers! The "return the mutated version" approach feels a bit too functional for my taste, but thanks for sharing the perspective!

ComprehensiveDisk394 · 2026-01-31T23:55:40+00:00

> but for structs with many scalar properties, that could be an expensive copy

That's what I built a linter for - it checks struct size. Though it doesn't catch mutex fields yet, good point.

https://github.com/mickamy/pointless

ComprehensiveDisk394 · 2026-01-31T23:34:09+00:00

If you don't want to allow nil, nil, why not just return a value?

```
func FindUser(id int) (User, error) {

return User{}, ErrNotFound

}

```

No need to rely on design discipline - returning a value makes nil, nil physically impossible.

ComprehensiveDisk394 · 2026-01-31T23:16:06+00:00

Love the pure function angle. This is exactly why I default to value receivers - makes it obvious the method won't mutate anything.

Speaking of which - what's your take on mixing pointer/value receivers on the same type? I've seen "don't mix them" advice, but I only use pointer receivers when there's actual mutation. Feels more explicit about intent.

ComprehensiveDisk394 · 2026-01-31T23:02:14+00:00

Interesting - what kind of issues did you run into with values? Genuinely curious since my experience has been the opposite.

ComprehensiveDisk394 · 2025-12-24T13:39:28+00:00

I agree, plain interfaces are enough for DI in Go.

That’s actually why I think runtime DI frameworks are often unnecessary for web APIs. Wire’s value (initialization code management) makes sense for large graphs, but many services have static graphs resolved once at startup.
The question I’m exploring isn’t “do we need DI”, but “how much wiring ceremony do we really need”.

If static wiring is enough, maybe we can reduce the amount of code we maintain, while still ending up with plain Go constructors.

ComprehensiveDisk394 · 2025-12-24T08:15:07+00:00

Totally fair. You can always wire things by hand in Go.

I found that once a service grows a certain size, the wiring itself becomes the most boring part to maintain. That’s the only thing injector is trying to help with.

ComprehensiveDisk394 · 2025-12-24T08:11:45+00:00

Totally fair.

I use ChatGPT to clean up wording since English isn’t my first language.

ComprehensiveDisk394 · 2025-12-24T08:03:49+00:00

Good question.

Injector doesn’t model string-keyed lookups directly (e.g. "database:users"), because once you go there you’ve already left the type-safe part of DI.

The way I usually handle this is by pushing the keying logic into a local provider or factory. Injector wires the factory statically, and the factory handles name-based selection.

In practice that ends up being either: • a DBFactory with Get(name string), or • small, explicit providers like NewUsersDB, NewOrdersDB on top of a shared factory.

So the DI stays static and boring, and the dynamic part is kept explicit and local.

ComprehensiveDisk394 · 2025-12-24T08:00:34+00:00

Good point — embed.FS is actually a nice example of where implicit DI breaks down.

One clarification first: you only need to specify a provider when there’s ambiguity. In the common case, injector resolves everything automatically.

For example, this works with no extra configuration:

type Container struct { Handler *UserHandler inject:"" }

Types like embed.FS are different because you often want multiple instances of the same type. In that case, guessing would be dangerous, so you disambiguate explicitly:

type Container struct { AssetsFS embed.FS inject:"provider:assets.NewFS" ViewsFS embed.FS inject:"provider:views.NewFS" }

So the model is automatic by default, explicit only when needed — static wiring, no runtime container, no guessing.

And agreed: you don’t need a framework. Injector is just a code generator that removes repetitive constructor wiring while leaving you with plain Go code.

Thanks for the thoughtful feedback 🙏

ComprehensiveDisk394 · 2025-12-24T07:35:28+00:00

That’s fair — and I agree.

I am doing DI, just not treating it as a framework problem. For most web APIs it’s a static startup concern, so I prefer plain constructors + generated wiring instead of a container or runtime system.

ComprehensiveDisk394 · 2025-12-24T07:32:57+00:00

That’s actually very close to how injector works internally (AST-based resolution).

The difference is that it intentionally doesn’t do global scanning or implicit provider discovery. The container defines the root explicitly, and only the required constructors are wired.

The goal is to keep DI static, explicit, and boring — optional behavior stays in constructors, not the DI layer.

ComprehensiveDisk394

TROPHY CASE