proposal: library of common actions

[vlcinsky]

The idea is to provide a python package (or packages), which would offer tools for simple actions (not tasks) such as:

• common file operations (copy, move/rename, mkdir, rmtree..)
• extended file operations (create an archive, unarchive...)
• great inspiration can be found in library of such tools for Gulp or Grunt.

The package would be external to doit to keep the core clean.

And it would strongly simplify (and shorten) amount of code to put into dodo.py.

Writing cross-platform dodo.py would be much easier.

Proposed resolution of this issue:

• set up new repository (e.g. doit-action-library)
• mark it as experimental one
• play with this topice there, possibly discuss ideas and issues in given repository issues.

[schettino72]

Well there is https://github.com/pydoit/doit-sys and https://github.com/pydoit/doit-web I am not sure I ever released/documented this things.

If you look projects like Ansible/Grunt and others these kind of packages have thousands of pull-requests. In doit it is so easy to write your own that I am not sure it is worth to have a third package.

It would be acceptable only if:

• it was completely configurable (so users do not need to patch).
• self documented, otherwise the complexity to look the docs is bigger than writing a bit of glue code.

Also I was doing some experimentation when I wrote those.

[vlcinsky]

There can be few levels of such libraries:

• level 0 "snippets": collection of snippets providing typical constructs in dodo.py, preferably with pure python
• level 1 "pure python lib": pure python (without calling shell commands). This allows for cross platform usage, especially when commands differ on platforms. This was the idea.
• level 2 "adapter to other cli": deploying some other tool, e.g. called via command line. If the tool is easy to install and use and it has wide set of features reusable in our dodo.py files, we can gain a lot just by joining doit forces with that library.
• level 3 "whatever comes": library of any sort of actions disregarding Linux/Windows portability.

I am aware of complexity of such task and it can be disaster to usability and create too much requirements to our support. For that reason:

• if we do it, we shall experiment first without going to big scale
• we shall not be responsible for maintaining those libraries (gulp and grunt also do not maintain the libs on their own, they just allow publishing, searching and using the tools).
• we shall reuse existing infrastructure (as pypi.python.org etc) with minimal support to features we feel as required for that purpose.

I consider this as possible long term goal.