New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow configuring loader root, collection, etc values #310

Closed
bitprophet opened this Issue Jan 20, 2016 · 6 comments

Comments

Projects
None yet
3 participants
@bitprophet
Member

bitprophet commented Jan 20, 2016

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

This comment has been minimized.

marcstreeter commented 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

This comment has been minimized.

Member

bitprophet commented Jul 7, 2017

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

@bitprophet

This comment has been minimized.

Member

bitprophet commented 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 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

This comment has been minimized.

dmulter commented Jul 7, 2017

+1 for last option from @bitprophet above if possible

@bitprophet

This comment has been minimized.

Member

bitprophet commented 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.

@bitprophet

This comment has been minimized.

Member

bitprophet commented 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 :))

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment