Live data from Hacker News

PyInfra 3.8.0

github.com

91–100 of 110 posts

Re: PyInfra 3.8.0

#91
post #73
post #51

Earlier quoted context omitted.

It obviously was LLM assisted, but I think collectively we will have to get over our distaste for text that has some LLM’isms in spots as long as it isn’t obviously completely outsourced to a bot, unless we just want to shut down message boards completely.

English is not my first language, so I lean on an LLM to clean up the frenchisms, but the ideas are mine :-)

Frenchisms are great! “No A, No B, No C. Just D” in every comment “assisted” by AI isn’t that great :(

Re: PyInfra 3.8.0

#92
post #74

Earlier quoted context omitted.

Many domains are better served by a more limited programming language, so you can analyze a program and/or make guarantees about it. Real regexes (actually regular…) are infinitely better than Python code matching the same string (if they are sufficient) - you can compute their intersection, union, complement; check if they can match anything at all (and generate an example automaticallly). For software builds, Bazel…

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.

Re: PyInfra 3.8.0

#93
post #51

Earlier quoted context omitted.

It obviously was LLM assisted, but I think collectively we will have to get over our distaste for text that has some LLM’isms in spots as long as it isn’t obviously completely outsourced to a bot, unless we just want to shut down message boards completely.

What was the obvious part in it? I still can't tell.

A sentence. Another sentence. Not a subordinate. Just single verb sentences.

But tbh I didn't see it much on OP's comment.

Re: PyInfra 3.8.0

#94
post #5

Has anyone used this and ansible and is able to give a short comparison with likes and dislikes?

Adding to sibling comments: I used to use Ansible professionally and PyInfra for homelab. Ansible is ridiculously slow.

The only issue was I had to implement some facts and operations myself that probably were available in some Ansible package but to be honest it was trivial.

Re: PyInfra 3.8.0

#95
post #7

This seems cool, I'd particularly be interested if their 10x faster than Ansible claims pan out. Has anyone here used PyInfra? If so what's your experience been like?

10x faster is probably underselling it given my experience with both. PyInfra is very fast.

Re: PyInfra 3.8.0

#97
post #2

Disclosure: PyInfra core contributor here. We just shipped 3.8.0. PyInfra is an agentless infrastructure automation tool. Same job description as Ansible, Salt, Chef. SSH into hosts, describe desired state, it diffs and converges. No agent, no central server, no daemon. The difference: your "playbook" is just Python. Not Python cosplaying as YAML. Not Jinja smuggled inside YAML inside a Helm chart inside a Kustomize…

> The honest move is to admit you wanted code, then write code

This war will never end ... because there are genuine tradeoffs on both sides. YAML being a bad data description format isn't actually central to the question of whether you describe infra as data or as code. You can use JSON if you want. Data is static, 100% predicatable. Code is non-deterministic right up to the halting problem. If your infra should look different on wednesday to thursday, well it can do that! Some people like it, some people think it's the definition of hell.

Terraform makes an interesting tradeoff to try and have the best of both worlds but ultimately still falls on the same issue ... I've not seen one project yet of any complexity that didn't use workarounds to implement optional components (let's just pretend there's a list of them and it has 1 or zero elements in it!).

Ultimately I agree with your philosophy but maybe not your language. IMHO You really want a language that is built from the ground up around static typing and immutable constructs for this. Get as close to that predictable determinism as possible. But then, if the whole world knows python, I guess python it is.

Re: PyInfra 3.8.0

#99

Wanted to try PyInfra for a long while but this is a deal breaker: https://github.com/pyinfra-dev/pyinfra/issues/1242

Yeah, I understand your frustration. This is an issue with Paramiko which pyinfra relies on. We have been debating moving away from Paramiko, but it will take a while for that to materialize.

Re: PyInfra 3.8.0

#100
post #92

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 environment around the language can put in limits (on time, number of operations, etc.)

Convex does this well, replacing SQL (somewhat yaml-like sucky old declarative language) with JS/TS but in a well-locked-down environment with limits to ensure one mutation or query doesn’t take down the whole DB.

Post reply on HN