3 ms·

I knew giving specific examples would lead this way, that's not my point. This case has been handled. Others? There isn't anything really insightful here. Som

I knew giving specific examples would lead this way, that's not my point. This case has been handled. Others? There isn't anything really insightful here. Someone pleased with a script has not yet grown beyond the needs of it. Yay. The more portable/maintainable version of this is a playbook or whatever. Someone wrote and tested a better version of whatever Work Unit as a module. Wheel enthusiast is pleased with their finely polished, but not particularly traveled, wheel. It's great, but they're commodities and not seeing much. I would have done the same thing with 'ansible-pull' and zero code, in even less time/effort... but I also already know Ansible and bash. Configuration management tools are excellent at managing applications and configs. Who knew. Something else to suggest: systemd timers. At a glance info for scheduling of the job, instead of inferred from logs that may or may not have been recorded. You can also then actually declare your deployment needs networking. Eyeroll.jpg. This is great because the bar is so low. They'll generate a ton of useless logs if they lose networking, as-is. Long enough and the disk will fill: this is trying every minute.

cess11 3y ago
OK, and I wouldn't have used either Ansible or bash. I would have used picolisp, which is clearly superior for this task due to the flexibility that comes with the deep POSIX integration. When I think about excellent software Ansible isn't the first that comes to mind either. Clearly it's different for you, and the person who wrote the TFA doesn't agree with me either.
- bravetraveler 3y ago
  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

OK, and I wouldn't have used either Ansible or bash. I would have used picolisp, which is clearly superior for this task due to the flexibility that comes with the deep POSIX integration. When I think about excellent software Ansible isn't the first that comes to mind either. Clearly it's different for you, and the person who wrote the TFA doesn't agree with me either.

bravetraveler 3y ago
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.