> Treating python as a project level dependency rather than a system level dependency
Nobody is treating Python as a project level dependency. Your Linux distro treats it as a system level dependency, which is exactly why you encountered the problem you did.
When you create a virtual environment, that does not install a Python version. It just makes symlinks to a base Python.
Building Python from source, and setting it up in a way that doesn't interfere with the package manager's space and will cause no problems, is easy on major distros. I have access to over a dozen builds right now, on Mint which is not exactly a "power user" distro (I didn't want to think about it too much when I initially switched from Windows).
One place I would love to visit is the Tower of Hercules which was built in the first century and based on the original plans of the Lighthouse of Alexandria.
It was mentioned pretty deep in another thread, but this is just straight up user hostile
variable "my_list" { default = ["a", "b"] }
resource whatever something {
for_each = var.my_list
}
The given "for_each" argument value is unsuitable: the "for_each" argument must be a map, or set of strings, and you have provided a value of type tuple.
This is what you get if you want a declarative syntax. HCL doesn't have any concept of a for loop, and can't have any concept of a for loop— it's a data serialization format. Terraform can be transformed to and from JSON losslessly. The looping feature is implemented in Terraform.
Ansible's with_items: and loop: do the exact same thing with YAML.
The concept of repeated operations executing with respect to some condition is always going to be a bit different in declarative / functional constructs than in imperative ones. A purely functional language is never going to have the equivalent of: for (...) a++;
Good functional languages like Clojure make something like this awkward and painful to do, because it doesn't really make sense in a functional context.
I think you missed the error message; I wasn't whining about for_each syntax masquerading as if it was a property of the resource, I was pointing out the moronic behavior of attempting to iterate over a list of strings and being given the finger
It is claiming the provided thing is not a set of strings it's a tuple
The fix is
for_each = toset(var.my_list)
but who in their right mind would say "oh, I see you have a list of things, but I only accept unordered things"
It's not about them being ordered it's about them being unique. You're generating a resource for each element and that resource has a unique name. The stackoverflow way to iterate over a list is to use toset() but more often what people want is
zipmap(range(length(var.my_list)), var.my_list)
where you get {0 => item, 1=>item} and your resources will be named .0, .1, .2. I get the annoyance about the type naming but in HCL lists and tuples are the same thing.
I'm confused by your question, lists don't enforce uniqueness—you can do ["a", "a"] and it's perfectly valid. Sets and the key values of hash maps can't have repeating elements. You can for_each over lists that come from a data block so you can't statically know if a list is effectively a set.
If you don't want .0, .1 then you agree with Terraform's design because that's the only way you could for_each over an arbitrary list that might contain duplicate values. Terraform making you turn your lists into sets gets you what you want.
I just tell people to avoid writing loops in Terraform if it could be at all avoided. And if you iterate make sure it’s a keyed dictionary instead of array/list like data structure
i'm not particularly fond of sweets in my adult life but in my child years it was something i loved. i don't know why anyone would think a child wouldn't like a sweet ball of treat
That seems terribly unfair to marshmallows. Smores, lucky charms, rice krispies treat/bubble slice, and hot chocolate wouldn't be the same without them.
On a more serious note, given that a triple-digit number of employees have taken buyouts over Matt's behavior, it must really suck to be one of the employees who now has to do other people's jobs in addition to their own.
If I worked for Automattic, I'd take a buyout even if I didn't object to Matt's behavior, just because I know how much it always sucks to be one of the employees stuck at a company after a walkout or a layoff.
To be fair, it's not accurate to assume or even imply they left because of Matt's behaviour. As even you go on to say, the incentive to leave - full stop - was there. Why not take advantage of the opportunity?
The whole "but once you leave there will be a Scarlett Letter on your HR folder's head (i.e., you will never be allowed back)" just sounded silly. Who knew Matt was a Taylor Swift fan?
Treating python as a project level dependency rather than a system level dependency is just an excellent design choice.