Skip to content
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

Trouble loading the project-level configuration file #234

Closed
brutus opened this issue Apr 11, 2015 · 10 comments · Fixed by #243
Closed

Trouble loading the project-level configuration file #234

brutus opened this issue Apr 11, 2015 · 10 comments · Fixed by #243

Comments

@brutus
Copy link

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 tasks.py file, but it is ignored. Values from ~/.invoke.yaml are loaded though. If i use -f it works too.

The tasks.py imports some tasks from other modules, but the root namespace is created and configured in the tasks.py 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 __init__.py) or in the parent folder (tried both, none worked)?

@jw
Copy link

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 tasks.py file.

@brutus
Copy link
Author

brutus commented Apr 28, 2015

I put the task.py 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
Copy link

jw commented May 1, 2015

Thanks @brutus, but there seem to be some issues with your gist. The task.py should be tasks.py, 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
Copy link
Author

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 tasks.py 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 tasks.py: 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.

https://gist.github.com/brutus/81b251c02cf2ae7c6ceb

@jw
Copy link

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.

@bitprophet
Copy link
Member

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
Copy link
Contributor

gtback commented May 5, 2015

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

gtback added a commit to gtback/invoke that referenced this issue May 5, 2015
When a `tasks.py` 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 pyinvoke#234.
@gtback
Copy link
Contributor

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
Copy link
Author

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 added a commit that referenced this issue May 5, 2015
bitprophet added a commit that referenced this issue May 5, 2015
@bitprophet
Copy link
Member

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
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants