Directory-resident tasks and global context?

[jonathaneunice]

I see how shovel works to execute tasks in the local directory. The handling of task definitions within a shovel directory is a bit more confusing, though. If I have a file shovel/one.py then I must invoke tasks as shovel one.taskname. Neither dropping the tasks into shovel/shovel.py nor into shovel/__init__.py allows me to do the simpler, unqualified shovel taskname style invocation. The ability to modularize / categorize functions seems great--but less so if it simultaneously evaporates the ability to do quick, unqualified access to the highest-level, most-used tasks.

Also, it seems that this might be very helpful as a front-end for various utility functions I need to run, but that would require a "global home base" like a ~/.shovel directory, and a means of running "top level" tasks without qualified names (as described above). Otherwise, I would constantly have to do some sort of cd ~/shovel before executing a shovel command, losing the current working directory (typical context in which tasks should be run), and re-complexifying task invocation.

[dlecocq]

That's a good point about the shovel/__init__.py availability -- I'll take a look at it and try to get it working.

I also like the idea of honoring ~/.shovel/ and / or ~/.shovel.py. The only thing I'm trying to figure out is how we'd handle collisions. For instance if there's a ~/.shovel/foo.py and a ./shovel/foo.py, or something similar. It's difficult to say whether they should be merged, with the more local copy replacing them, or if it should raise a warning about the collision.

[jonathaneunice]

I would say that local tasks (or task names) should override global task names. It's not going to be that common an occurrence, and the aliasing risk seems reasonable and understandable.

Esp. if you are interested in having a global task context (i.e. from ~/.shovel/ and / or ~/.shovel.py), I would recommend adding a --list command line parameter to identify the available tasks to the user (and possibly, display any overrides).

[dlecocq]

I think that's pretty reasonable. I think I would like to make note of overrides when listing tasks. If you just invoke shovel help, it does currently list available tasks

[dlecocq]

Just wanted to give an update -- I'm nearly done with some major refactoring (including actually having tests now) that will enable support for this.

[b4hand]

Looks like this was resolved by #19.