Infinite recursion under certain configurations on Windows about mockery HOT 10 CLOSED

FWIW, my latest patch (that closed this issue) fixes the behavior of showconfig so that we don't get into infinite recursion when using recursive: True

➜  mockery git:(master) ✗ ./mockery showconfig
05 Nov 23 22:23 CST INF Using config: /Users/landonclipp/git/vektra/mockery/.mockery.yaml version=v0.0.0-dev
disable-version-string: true
filename: '{{.MockName}}.go'
mockname: '{{.InterfaceName}}'
outpkg: mocks
packages:
  github.com/vektra/mockery/v2/pkg:
    config:
.....

from mockery.

This is not hardly the only issue on Windows, which certainly complicates fixing it.

from mockery.

So I'm not sure I understand. What exactly is the infinite recursion here? What do you notice when running that config? (does mockery spin infinitely and not give any output?)

from mockery.

I admit, I have spent 0 mental energy making mockery work for Windows. It hasn't been a huge priority because most people use unix-like systems. I'm honestly surprised mockery works at all on windows TBH because there are a lot of underlying things like in pathlib (which I wrote) that don't have any explicit support for Windows, although maybe that's not as much of an issue if you're using WSL.

from mockery.

So I'm not sure I understand. What exactly is the infinite recursion here? What do you notice when running that config? (does mockery spin infinitely and not give any output?)

It's a little difficult to get a good working output because the YAML encoder seems to run out of memory before it can print anything. Inferring from what I can see from spew.Dump, what seems to happen is that the configuration gets turned into something like the following (ignoring the parts that aren't broken):

packages:
  github.com/vektra/mockery/v2/pkg/fixtures/example_project/pkg_with_subpkgs/subpkg2/subpkg3:
    packages:
      github.com/vektra/mockery/v2/pkg/fixtures/example_project/pkg_with_subpkgs/subpkg2\subpkg3:
        packages:
          github.com/vektra/mockery/v2/pkg/fixtures/example_project/pkg_with_subpkgs/subpkg2/subpkg3:
            packages:
              github.com/vektra/mockery/v2/pkg/fixtures/example_project/pkg_with_subpkgs/subpkg2\subpkg3:
                ...

from mockery.

Oh, so you are saying that showconfig is getting into an infinite loop, not the actual mock generation?

from mockery.

I haven't tried generating mocks using the problematic configuration yet, so I don't know if mock generation is broken or not. I can test that later when I'm back on Windows. So far, this only arose for me in mockery's own tests.

from mockery.

I admit, I have spent 0 mental energy making mockery work for Windows. It hasn't been a huge priority because most people use unix-like systems. I'm honestly surprised mockery works at all on windows TBH because there are a lot of underlying things like in pathlib (which I wrote) that don't have any explicit support for Windows, although maybe that's not as much of an issue if you're using WSL.

That's fair, it may not be worth the time or effort if nobody really uses it on Windows. If the right answer is just to use Mac/WSL/Linux instead, maybe the right solution to this is just to add a note to the README that Windows isn't supported and move on.

from mockery.

Got it, so I think that this config would work fine for actual mock generation. showconfig has been broken since I implemented the recursive feature, I just never mentioned it and it seemed like no one actually ever used showconfig until now. I'm also not sure this has anything to do with Windows necessarily.

The problem lies with the fact that when using recursive: True, all discovered sub-packages will contain a copy of the parent package's config, including the package parameter itself. Because of this copying behavior, the package parameter gets into this infinite self-referential loop that is impossible to get out of. This isn't a problem for the mock generation because it doesn't recurse into the packages map, it only looks at the top-level packages map.

I did try fixing this like a year ago but obviously I gave up... I think the solution would be to nil out the packages map during the config inheritance step. It's not a great solution but I think it'd work.

from mockery.

There does seem to be something especially bad about it on Windows, where the path separator discrepancy (\ for the file system, / for Go packages) creates redundant entries in the packages map which I guess breaks the YAML encoder's cycle detection.

from mockery.