CODEWITHSUNDEEP
pythoncomparefabricplumbum
walkingpendulum
walkingpendulum

Reputation: 300

Fabric vs Plumbum: differences, use cases, pros and cons

What are pros and cons of Fabric and Plumbum python libraries for local/remote command execution? What are use cases when one library should be used and other is not? What are the differences attention should be drawn to?

Upvotes: 4

Views: 1364

Answers (2)

mvk_il
mvk_il

Reputation: 960

background and suggested comparison methodology

(oops it's a dead post)

Both tools are fun, allow either local or remote work, but have differences in the things they are supposed to solve, i.e. "terminology", and both are basically pretty much obsolete by modern deployment/automation tooling (like ansible, and many others that chose DSL way, e.g. terraform). Their advantage over more modern ones are lack of "opinionated" approach about the "how", and more on "what".

Suggested comparison criteria:

  1. "Pythonness" vs. "Shellness" (i.e. how "pythonic" the user code with each is)
  2. Special Capabilities
  3. ROI with 2 types of maintainers of your "automation" code (ops vs. devs, let's put "QA" as something in between)

Fabric (my last work was done at 1.8 take this with a grain of time salt):

  1. more pythonic, than shellish, this means easy to support by both old tools and new - i.e. editors, IDEs would be easy to setup
  2. many many context processors, many decorators, very nice
  3. easier to adopt by developers, a bit more traction would come from ops people

Plumbum

  1. The user code can be either pythonic or shellish
  2. "shell combinators" are a killer feature to get senior shell/perl folk onboard, but it uses dynamic imports, so editors/IDEs are a bit trickier to setup.
  3. Due to 1. You will get 'ops' people on board easier, because of mimicking shell constructs in Plumbum, but please install good coding conventions.

Epilogue

Having worked with both toolkits (with lots of fun) and then having switched to ansible - I feel confident to claim - both tools are now superseded by ansible. you can do most automation tasks with existing ansible modules, and what you can't - you can write a plugin or module for it (in any language), or just call shell module.

My consideration would be this:

  • if your team of maintainers has good level of programming skills (Esp. in python), as a requirement - you'd be ok with using either fabric, Plumbum (it has more cool hacks ;)) or Ansible.
  • if you have multi-level multi-team organization, I would simply bet on Ansible - it has lower learning curve, and allows to grow up easily.

Good day.

Upvotes: 3

2ps
2ps

Reputation: 15936

They're pretty much the same thing. The biggest win for fabric over plumbum is the ability to connect to multiple hosts in parallel, which is more or less indispensible when you're working with a non-trivial setup. fabric also offers a couple of contrib helpers that let you upload jinja templates, upload files, and transfer files back to the local system. I personally find the fabric api to be far more intuitive for working with remote servers.

YMMV, of course, but both are geared towards being very close to shell commands. That said, my team and I are focused on ansible for most configuration / deploy flows. Fabric does offer some power over ansible at the expense of having to roll your own idempotence.

Upvotes: 0

Related Questions