Invoke 2.1.0 / 2.1.1 is not able to read invoke.yaml configuration file about invoke HOT 10 CLOSED

2.1.3 now on PyPI!

from invoke.

Just installed it, I can confirm that it works as expected, many thanks!

from invoke.

@vaz-ar I wasn't able to reproduce this. You might have to provide additional details.

Example:

from invoke import task


@task
def check(ctx):
    print(ctx.test)

Config file:

$ cat ~/.invoke.yaml 
---
test: value

$ cat $PWD/invoke.yaml 
---
test: value

Both outputs gave:

$ inv check
value

from invoke.

@vaz-ar I wasn't able to reproduce this. You might have to provide additional details.

Example:

from invoke import task


@task
def check(ctx):
    print(ctx.test)

Config file:

$ cat ~/.invoke.yaml 
---
test: value

$ cat $PWD/invoke.yaml 
---
test: value

Both outputs gave:

$ inv check
value

Hello,

Thanks for your reply.

Here is the smallest example I was able to make to reproduce the problem, I uploaded it to gist: https://gist.github.com/vaz-ar/dac367545b16b905f070d56391acaae3

the https://gist.github.com/vaz-ar/dac367545b16b905f070d56391acaae3#file-dir_tree-txt show the directory structure.

I reproduce the problem by placing mysefl in the /tmp/inv_test dir and running inv testcheck.check

from invoke.

I just tested and the issue is also there with 2.1.2

from invoke.

I'll check it out tonight.

from invoke.

We have the issue as well; our builds broke when we went from 2.0.0 -> 2.1.2.

The structure of our project is

tasks/
|-- __init__.py
|-- a.py
|-- b.y

And we would call invoke a.foo or whatever, but use an invoke.yml in the top level directory.
In 2.1.2, it seems like the invoke.yml has to be in the tasks/ directory to get recognized.

from invoke.

Apologies, took longer than I expected to get some free time.

Confirmed:

invoke.loader.find: FilesystemLoader find starting at '/tmp/example'
invoke.loader.find: Found module: ModuleSpec(name='tasks', loader=<_frozen_importlib_external.SourceFileLoader object at 0x7fe419984760>, origin='/tmp/example/tasks/__init__.py', submodule_search_locations=['/tmp/example/tasks'])
invoke.config._load_file: Didn't see any /tmp/example/tasks/invoke.yaml, skipping.
invoke.config._load_file: Didn't see any /tmp/example/tasks/invoke.yml, skipping.
invoke.config._load_file: Didn't see any /tmp/example/tasks/invoke.json, skipping.

from invoke.

Linking this to #934 since it's proximately related (same root cause - switching up how we find/import "the tasks") though I'm not yet sure if the right fix is anything like that one's was (which was literally about fixing import'ability, and this is more about ensuring the right location is looked at for the conf files).

Jesse's PR uses cwd which is only incidentally correct if you're sitting in the project dir; the best fix would be to identify the 'sibling' location to the tasks package. I am looking at this now. Also, why did tests not turn this up? We don't have the same excuse as the import problem, AIUI, so there may just be a missing test.

from invoke.

Fix identified, tests updated/added (real problem was in the Loader class, the changes to use importlib missed this case, as expected because there was a missing test or two), changelogged. Testing on the dayjob machine before I merge.

from invoke.