Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PyInfra 3.8.0

github.com

Post reply on HN
Print view View original

101–110 of 110 posts

Re: PyInfra 3.8.0

#101

Post by VectorLock »

beagle3 wrote: post #92
VectorLock wrote: post #87

Earlier quoted context omitted.

The "you don't want a full programming language" trope I see repeated a lot but I think far more people end up wishing for a Turing complete language than wishing it _wasn't_ Turing complete.

They do, until a configuration endless loop brings down their production system. This is not really different than C vs Rust, or even Perl regular expressions (unbounded execution time) vs real regular expression. With great powers comes great abilities to shoot yourself in the foot. The power/guarantee balance is delicate, and you can’t hold the stick at both ends. People will always complain.

The number of times I've seen a configuration endless loop bring down anything are so few compared to the time wasted on DSLs and having to bend over backwards to do things a first-class programming language can do simply. Same with PCRE I've seen that maybe.. once.

Re: PyInfra 3.8.0

#102

Post by vardalab »

rirze wrote: post #62
vardalab wrote: post #54

Earlier quoted context omitted.

Yeah, but I have Claude Code or Codex do this Ansible stuff and they do just fine with all this and then there's a gazillion of examples that they can lean on and once the patterns are established, it's pretty smooth. Opus 4.5 was when the big inflection was I was heavy into automation all summer. It was Opus 4.0. It was like pulling teeth. And then when 4.5 came out, it was just beautiful.

Yeah, you’re gonna eat your words when you do something that’s not “install this package” and “create this user”. For anything dynamic and sufficiently complicated, ansible is horrible. Pyinfra is much better.

I disagree. The rigidity of YAML and stuff like that is what actually makes LLMs work better. I have strict linting rules and file size limits and it imposes discipline on LLMs. That's why it worked even last year. Even before Opus 4.0 it worked to some extent as long as you imposed discipline on these models Trust me, I do pretty complicated things with Ansible, key thing is to have decent established patterns and these models truly are getting better.

Re: PyInfra 3.8.0

#103

Post by rirze »

vardalab wrote: post #102
rirze wrote: post #62

Earlier quoted context omitted.

Yeah, you’re gonna eat your words when you do something that’s not “install this package” and “create this user”. For anything dynamic and sufficiently complicated, ansible is horrible. Pyinfra is much better.

I disagree. The rigidity of YAML and stuff like that is what actually makes LLMs work better. I have strict linting rules and file size limits and it imposes discipline on LLMs. That's why it worked even last year. Even before Opus 4.0 it worked to some extent as long as you imposed discipline on these models Trust me, I do pretty complicated things with Ansible, key thing is to have decent established patterns and t…

That's not my point at all.

When you have 6 stanzas to perform a dynamic if/else branch, the underlying system if flawed.

Models can overcome the complexity of ansible-- I argue that they shouldn't be. Ansible is a flawed framework.

Re: PyInfra 3.8.0

#104

Post by subhobroto »

jimmcslim wrote: post #88
subhobroto wrote: post #25

Congrats on shipping 3.8.0! If you're a software engineer who wants to setup and maintain infrastructure, give PyInfra and Pulumi a go! Huge fan of PyInfra. For my homelab, I use Pulumi with Python and PyInfra to build fully declarative intent based infrastructure. You can use actual software engineering principles like composition, inheritance, DI to setup and wire your infrastructure and services. One of the benefi…

Can you explain how you combine PyInfra and Pulumi? It feels like these are mutually exclusive projects?

IMHO PyInfra and Pulumi are complementary.

You can substitute Pulumi for Terraform, PyInfra for Ansible and google for sample projects that use Terraform and Ansible to get a good idea of their strengths and how they come together.

Then, you take that understanding and you realize using PyInfra and Pulumi, you can do all of that in just Python, using all of Python's rich ecosystem.

Re: PyInfra 3.8.0

#105

Post by crispyambulance »

beagle3 wrote: post #92
VectorLock wrote: post #87

Earlier quoted context omitted.

The "you don't want a full programming language" trope I see repeated a lot but I think far more people end up wishing for a Turing complete language than wishing it _wasn't_ Turing complete.

They do, until a configuration endless loop brings down their production system. This is not really different than C vs Rust, or even Perl regular expressions (unbounded execution time) vs real regular expression. With great powers comes great abilities to shoot yourself in the foot. The power/guarantee balance is delicate, and you can’t hold the stick at both ends. People will always complain.

A lot of this is a matter of taste and judgement.

In the same way that it's possible to have an xml/json/yaml/toml config that creates despair in those who have to maintain it, a python or bash script can grow into a monster in the basement.

Or, it could be a cogent script that makes its intent and operation obvious. I prefer that when possible.

Re: PyInfra 3.8.0

#106

Post by HALtheWise »

beagle3 wrote: post #92
VectorLock wrote: post #87

Earlier quoted context omitted.

The "you don't want a full programming language" trope I see repeated a lot but I think far more people end up wishing for a Turing complete language than wishing it _wasn't_ Turing complete.

They do, until a configuration endless loop brings down their production system. This is not really different than C vs Rust, or even Perl regular expressions (unbounded execution time) vs real regular expression. With great powers comes great abilities to shoot yourself in the foot. The power/guarantee balance is delicate, and you can’t hold the stick at both ends. People will always complain.

This is exactly what the Starlark language was developed to solve, initially for Bazel but also used other places. It's a "full scripting language" but intentionally doesn't (in default configuration) support recursion or unbounded loops, so is deterministic and bounded execution time. I really wish more projects would reach for it as a configuration language.

https://github.com/bazelbuild/starlark

Re: PyInfra 3.8.0

#107

Post by bmurphy1976 »

sgarland wrote: post #36

Never heard of this before. In looking through docs, honestly it looks like Ansible, but for people who don’t know Ansible, and with way more footguns. The fact that you can import any existing Python library means you’re now relying on those libraries to not introduce bugs, or throw an exception in the middle of an operation, etc. I despise YAML, but I can appreciate that it makes it harder to introduce imperative l…

You can build spaghetti in anything and that definitely includes Ansible.

Re: PyInfra 3.8.0

#108

Post by ssousa666 »

HALtheWise wrote: post #106
beagle3 wrote: post #92

Earlier quoted context omitted.

They do, until a configuration endless loop brings down their production system. This is not really different than C vs Rust, or even Perl regular expressions (unbounded execution time) vs real regular expression. With great powers comes great abilities to shoot yourself in the foot. The power/guarantee balance is delicate, and you can’t hold the stick at both ends. People will always complain.

This is exactly what the Starlark language was developed to solve, initially for Bazel but also used other places. It's a "full scripting language" but intentionally doesn't (in default configuration) support recursion or unbounded loops, so is deterministic and bounded execution time. I really wish more projects would reach for it as a configuration language. https://github.com/bazelbuild/starlark

I have such mixed feelings about Starlark and Bazel macros. When I write Bazel macros, they're great, the perfect tool for the job. When I encounter macros written by someone else, they are awful, a mistake and the bane of my existence.

Re: PyInfra 3.8.0

#109

Post by sgarland »

bmurphy1976 wrote: post #107
sgarland wrote: post #36

Never heard of this before. In looking through docs, honestly it looks like Ansible, but for people who don’t know Ansible, and with way more footguns. The fact that you can import any existing Python library means you’re now relying on those libraries to not introduce bugs, or throw an exception in the middle of an operation, etc. I despise YAML, but I can appreciate that it makes it harder to introduce imperative l…

You can build spaghetti in anything and that definitely includes Ansible.

Sure - but it’s easier to spot and squash. Banning the use of the command and shell modules eliminates a majority of spaghetti / idempotency footguns.

Re: PyInfra 3.8.0

#110

Post by eliaspro »

bijowo1676 wrote: post #46
pbronez wrote: post #40

How does this compare to Salt Stack? “Built on Python, Salt is an event-driven automation tool and framework to deploy, configure, and manage complex IT systems. Use Salt to automate common infrastructure administration tasks and ensure that all the components of your infrastructure are operating in a consistent desired state.” https://docs.saltproject.io/en/latest/topics/about_salt_proj...

salt is heavy: it has client, server, agent. it equires installation, consumes resources, etc. pyinfra is just python that gets transpiled into ssh commands

I wouldn't call it heavy, but more complex instead. Salt is astonishingly lightweight (at least before they started vendoring everything and I stopped using it) and extremely fast - due to its execution model it doesn't really matter whether you target 10 or 10000 nodes with a job.
Post reply on HN