#random (2021-05)

asdf is awesome. In addition to having different versions of python/node/ruby/etc, there are also plugins for installing a large number of tools.

https://github.com/asdf-vm/asdf-plugins

can you paste an example for me and others to see?

Totally! Best tutorial I can give is the source. https://github.com/asdf-community/asdf-direnv

I would love to see how I can use this in the Terraform+AWS ecosystem, so I can integrate this with my Terraform Taskfile

Go through this process, then for your project directories, you need to set up a .envrc (which I can post an example of my python projects here if you like) and a .tool-versions file (both of which I globally git ignore to save me committing them to VCS)

that’s exactly what I do

I use asdf to manage terraform

I’m already big fan for direnv and using it already

nice

and direnv to manage the version based on the project I’m in, works like a charm

awesome

happy hunting!

for group/team projects, couldn’t you include the config in RCS so that others use the same tool versions? I know TF has the required_version = "~> 0.14" setting in the code, but seems like you could have another point of enforcement with the direnv and/or tool-versions config in place.

I should say i am hyper sensitive on this point after being pulled into projects where the team is still on 0.12 and my env is set up to use 0.14 and 0.15

I think if .tool-versions was a widely used thing I’d be super down with that. So far I’ve only seen asdf use it (I think?) so I prefer keeping it out of shared projects because it’s a config file specific to a tool I use

Unless of course you get buy-in from your whole team to want to use asdf then yeah, it would be good

I also have to deal with a few versions of Terraform and it used to be quite painful

agree. i also go back and forth about including/excluding VS Code configs in RCS. if its the standard tool, then the whole team can benefit. it not its another annoying/confusing file in the repo

for TF versions i am using tfswitch

https://tfswitch.warrensbox.com/

there are lot of tools for managing tf versions and even Terragrunt like tfenv and tgenv, but this adsf allow you to includes other Terraform helpers like terraform-docs , tflint, tfsec …. among other tools, so in your makefile or taskfile you only include one tool for managing terraform dependencies (helpers)

I wonder what so special about this distributive is:)

I saw this on Reddit! Looks kinda awesome. Theoretically Logstash can achieve all the same stuff as this project right? Or am I missing something?

It takes inputs, processes them based on Bloblang and the sends them places?

Logstash can achieve all the same stuff as this project I haven’t used Logstash in awhile but I’d be shocked if it can do all of the inputs/outputs that benthos is claiming
processes them based on Bloblang Bloblang is 1 of many different processors it can execute. https://www.benthos.dev/docs/components/processors/about

Cool just trying to scope out what it can do vs. what we deploy right now. Logstash acts as fantastic glue for a lot of things, as well as being good for logs

For reference https://www.elastic.co/guide/en/logstash/current/input-plugins.html

Are you related to the project? I’d love to see a more complex example project of it in use

Nope I just saw it mentioned on reddit too

It looks really useful though, we have several in-house apps that I think I could replace with benthos deployments

Yeah nice, kinda the same. I used logstash and grok to achieve what benthos does with bloblang

It replaced some python apps we maintained

Logstash is great but always good to be aware of other solutions I guess

It’s more about logs and metrics (rather than “data”) but I think also Vector (https://vector.dev/) it’s worth to be take into consideration. It looks very promising.

nice to meet you! @Bogdan Romaniuk!

maybe copier? https://github.com/copier-org/copier

perhaps in conjunction with git-xargs? https://github.com/gruntwork-io/git-xargs

Will take a look, thanks:)

we did, from jenkins to argo cd

https://medium.com/qonto-way/how-we-scaled-our-staging-deployments-with-argocd-a0deef486997

@Issif very nice, thanks for the article