Randy Syring

> Sorry if it was not so obvious to me. When I replied to @rsyring I thought we were discussing unittest style. Sorry for the confusion. I meant xunit _style_...

FWIW, I did some experimentation this morning: https://github.com/level12/pytest-xunit-fixtures/tree/cf0cffd184548bddf0c7ab99cf9ad9d61e2a1cea (not everything here is expected to work currently, in fact most won't work). and here are the issues I've ran into so...

> @rsyring would using a class decorator be acceptable? @nicoddemus thanks for asking. For our use case which involves thousands of test classes across multiple projects it would be better...

@RonnyPfannschmidt As I [wrote above](https://github.com/pytest-dev/pytest/issues/5289#issuecomment-1073027092), unless I've missed something, it's demonstrably false that "just add a fixture" is a reasonable solution for the use cases this issue is concerned with....

FWIW, I evaluated Docker Swarm for a short time last year. For my use case of a handful of servers with relatively minimal complexity, it seemed like it would be...

Could be related if the resolution to this is a stable/deterministic ID for a host that can be used in Terraform: https://github.com/tailscale/tailscale/issues/1532

@davidsbond thanks again for the time you are taking to discuss all of this. Since we don't have a real provider that is creating the device and, under the hood,...

> So you could obtain the specific device using the hostname you provide the tailscale up command if the tailscale_device data source is updated to allow you to query on...

Just making the implicit explicit: we have a chicken and egg problem here between Tailscale's operational model and Terraform's. Since the models are currently incompatible, some kind of workaround is...

FWIW, I would really like to see: * the ability to set indexing options on each path * a recursive flag on each path or ability to set depth (my...