Trouble loading the project-level configuration file #234

brutus opened this Issue Apr 11, 2015 · 10 comments


None yet

4 participants

brutus commented Apr 11, 2015

I'm using Invoke 0.10.1 in an virtual environment. I have an invoke.yaml file next to my file, but it is ignored. Values from ~/.invoke.yaml are loaded though. If i use -f it works too.

The imports some tasks from other modules, but the root namespace is created and configured in the file. I tried using a package for the tasks instead but to no avail.

Any hints?

And btw: if I use a package, do the invoke.yaml file needs to be in the package (next to or in the parent folder (tried both, none worked)?

jw commented Apr 26, 2015

Weird. Works for me. Can you add your invoke.yaml and .invoke.yaml files to the issue?
And the invoke.yaml needs to be in the same folder as your file.

brutus commented Apr 28, 2015

I put the and invoke.yaml files here as a gist. Both are in the same directory at the top level of the project.

I currently use no ~/.invoke.yaml file, but when I create one for testing purposes it works. It also works if I use the -f parameter: inv -f invoke.yaml sometask woks, inv sometask not.

jw commented May 1, 2015

Thanks @brutus, but there seem to be some issues with your gist. The should be, the corelib module is unkown, not is the setup, clean, css_ns,... tasks. I've created another gist for you. Could you please give it a try?

brutus commented May 1, 2015

Thank you: your example works in any case, I came up with. And sorry, the missing s in my gist's was a typo and corelib is some project local stuff.

But I assure you, the example gist works for me — but only if I include the invoke.yaml trough the -f option, else the data is not loaded, although both files are in the same directory and named correctly. If I store the data in the namespace configuration instead, it works too.

What seems to be the problem is, that I'm using a namespace in my When I don't create a namespace — like in your example — the data from invoke.yaml is loaded. When I create a namespace it's not. It doesn't matter if I configure it, as soon as the namespace is created, the data is not loaded.

jw commented May 3, 2015

You're right, when using a ns = Collection() at the bottom on my gist, the project yaml is not read. You can see that when running invoke with the -d option. This is a bug related to #210.


Wacky times, thanks a lot for reporting and kicking this around! I will try to reproduce this on my end soon, I don't personally use project-level conf files yet (though I do use explicit namespaces everywhere) so I haven't had a chance for it to bite me. But it sounds totally plausible and hopefully there's a simple, silly answer.

gtback commented May 5, 2015

I've been digging around and think I solved this one. PR coming shortly.

@gtback gtback added a commit to gtback/invoke that referenced this issue May 5, 2015
@gtback gtback Pass in project directory when tasks module contains explicit namespace.
When a `` module contains an explict Collection (named either `ns`
or `namespace`), the parent directory (used to find the project-specific
configuration file (e.g. `invoke.yaml`) is not passed in to the
Collection created from the factory method `Collection.from_module`.
This caused the file to not be found except when explicitly specified
with the -f flag. Compare to the similar Collection() invocation about
12 lines below this change.

Fix #234.
gtback commented May 5, 2015

@brutus: Can you see if the change I made in 34e6a7a solves the problem for you, in case @bitprophet doesn't have a chance to reproduce this bug?

brutus commented May 5, 2015

@gtback: Just did a quick check and it worked. Thx! Will fiddle some more and get back to you if anything bails.

@bitprophet bitprophet closed this in #243 May 5, 2015
@bitprophet bitprophet added a commit that referenced this issue May 5, 2015
@bitprophet bitprophet Add test proving #234 3356f62
@bitprophet bitprophet added a commit that referenced this issue May 5, 2015
@bitprophet bitprophet Changelog fixes #234 b67cd6f

Thanks to all 3 of you for poking at this

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