Repository navigation
Allow configuring loader root, collection, etc values #310
Description
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?
Activity
marcstreeter commentedon Apr 4, 2016
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 commentedon Jul 7, 2017
There are some extra thoughts and info in #291, make sure that is considered before we work on this.
bitprophet commentedon Jul 7, 2017
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 theProgramclass into a local Invoke-derived runtime (such as Fabric 2's version offab). It's a reasonably lightweight way to generate a 'binary' which behaves exactly likeinv/invokeexcept 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. ButProgram+ asetup.pyspecifying an entrypoint is often easier to distribute, since it works as soon as one's code ispip 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.ymlcould override the collection-related bits, e.g.:(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
Configlifecycle.dmulter commentedon Jul 7, 2017
+1 for last option from @bitprophet above if possible
bitprophet commentedon Jul 25, 2017
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.
More DDD re #329, re #310
Overhaul namespace-loading doc re: #310
bitprophet commentedon Jul 27, 2017
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 :))