Allow configuring loader root, collection, etc values

[bitprophet]

I.e. users should be able to configure how task collections are loaded, from global or per-user config files, and have those serve as the defaults for --root, --collection etc.

This way users can easily set up a default set of tasks for invoke if they're not in a folder or tree containing a tasks.py.

It's possible this will require improving the loader process itself so there's a concept of default + override, since otherwise, anybody setting this kind of 'default tasks location' value might find it 'blocking' the current load behavior unintentionally. But hopefully we can simply leverage the regular ol' configuration hierarchy for this?

[marcstreeter]

So basically this feature would allow someone to run an invoke script on a server without having to make external systems cognizant of where the script is located -- +1 :)

[bitprophet]

There are some extra thoughts and info in #291, make sure that is considered before we work on this.

[bitprophet]

And there's also another request in #455, which prompted me to rethink things a bit (now that we're 2 years of new features into the codebase...)

The currently-functional "best" workaround for the problem of "I want to default to loading something other than tasks/tasks.py" is to leverage the Program class into a local Invoke-derived runtime (such as Fabric 2's version of fab). It's a reasonably lightweight way to generate a 'binary' which behaves exactly like inv/invoke except for minor tweaks - such as where tasks are sought by default. Docs here.

Arguably this is even more easily served by requesting users to just add alias our-inv="inv -c invfile" to their shell dotfiles, of course. But Program + a setup.py specifying an entrypoint is often easier to distribute, since it works as soon as one's code is pip install'd.

---

That said, there may be another option too. I don't recall off the top of my head if it's feasible (small chance it even "just works" right now, actually!) but we might be able to ensure basic config bits are loaded/honored before collections are. Then your invoke.yml could override the collection-related bits, e.g.:

tasks:
    collection: invfile

(That's not the real config setting; I don't think it actually exists yet, at least not publicly.)

There's a bit of chicken and egg here (part of the config system includes data loaded from the task collection!) but that's already a semi-solved problem (for other reasons) so it probably just means additional tweaks to the Config lifecycle.

[dmulter]

+1 for last option from @bitprophet above if possible

[bitprophet]

Been doing this + #329 at the same time as the core need is the same (Config handy earlier in process and in more parts of the system). Most notes-to-self have been over there. FYI.

[bitprophet]

This is in! and will be released momentarily in v0.20. Changelog says all, tl;dr should be able to set tasks.collection_name (similar to above example) in a system or user config file. (Not project conf files, unfortunately, since finding those is predicated on finding a task collection first! At least at present :))