7 ms·

Let's take a step back from names for a second - I feel we're getting a little distracted by that. My gripe isn't with the tech, or even the solution. It's per

Let's take a step back from names for a second - I feel we're getting a little distracted by that. My gripe isn't with the tech, or even the solution. It's perfectly fine. I know I'm being overly critical, but I think they opened themselves to some judgement by making a post! I would do something very similar. Sure, the tool wouldn't have the exact same name, but the mechanism would be ~the same~ very similar. If the goal is to minimize surprises, the amount of effort put into something, etc - is it not best to follow the beaten path? They're to be commended for making a solution that works well for them, and echoing the KISS methodology, I just don't think a shell script is it. Anecdotes are funny, I guess. It's worked well for them - but I'm here because similar things have gone terribly for me. Small decisions can have big influence

cess11 3y ago
Pretty sure bash and Perl and C (and make and autotools and probably something I'm forgetting) are the beaten path in this context, i.e. software building and deployment on Unix. Ansible has surprised me way more often than bash has. The latter is upfront about being weird and a little bit insane, Ansible tries to have a better image. In my experience that is true also for Puppet and some other similar tools, which I'd never use without payment, at least until I can afford personal medium iron somewhere and need to provision and handle hundreds of more or less ephemeral virtual machines. In part because I enjoy having pets rather than herds in my personal projects, but also because when using the shell or POSIX there's very little overhead, like venv and python libs and so on that will inevitably irritate me a few times a year even if I rarely use them directly.
- bravetraveler 3y ago
  Bash/Perl/C being precursors don't disqualify Python/Ansible, though. Otherwise my retort would be this: assembly. While I empathize, your experience isn't [widely] representative. A reproducible Python environment is just as attainable as any other - anyone struggling with it has accepted it, in my opinion. Most of my peers/community uses the distribution packages. They don't even need to care about venv/pip at all.

cess11 3y ago

Pretty sure bash and Perl and C (and make and autotools and probably something I'm forgetting) are the beaten path in this context, i.e. software building and deployment on Unix. Ansible has surprised me way more often than bash has. The latter is upfront about being weird and a little bit insane, Ansible tries to have a better image. In my experience that is true also for Puppet and some other similar tools, which I'd never use without payment, at least until I can afford personal medium iron somewhere and need to provision and handle hundreds of more or less ephemeral virtual machines. In part because I enjoy having pets rather than herds in my personal projects, but also because when using the shell or POSIX there's very little overhead, like venv and python libs and so on that will inevitably irritate me a few times a year even if I rarely use them directly.

bravetraveler 3y ago
Bash/Perl/C being precursors don't disqualify Python/Ansible, though. Otherwise my retort would be this: assembly. While I empathize, your experience isn't [widely] representative. A reproducible Python environment is just as attainable as any other - anyone struggling with it has accepted it, in my opinion. Most of my peers/community uses the distribution packages. They don't even need to care about venv/pip at all.