Mint Initialization not working

[gerber55555]

Describe the bug
Mint Initialization hangs after login, non-headless version shows login successful, but it never moves on to next step.

What version of MintAPI are you using?
1.66

What command[s] did you run / steps to reproduce?
on cmdline:
mintapi --keyring <email> --use-chromedriver-on-path

in python

mintapi.Mint(...) <-- Hangs here
mint.get_accounts()

Stacktrace/error received:
None

What did you expect to happen?
Expectation of mint api to return account information

What actually happened?
No data returned, hangs indefinitely with no error

Additional Context
Ran on RaspberryPi and Windows 10. Using Python 3.9.2

[gerber55555]

Apparently there is a new version of Mint that they are working on to support. If you pull the repo and build it locally you will be able to use it. Keeping this issue open until new version is released however.

[nickodell]

@gerber55555 Do you have this working? If so, which branch do you have working on? I tried branch main, at commit bc6e78c, and I ran into this error:

Traceback (most recent call last):
  File "./fetch.py", line 110, in <module>
    main()
  File "./fetch.py", line 60, in main
    accounts = mint.get_accounts()
AttributeError: 'Mint' object has no attribute 'get_accounts'

I'm not exactly sure why this method was removed - it's still mentioned in the README. It looks like it was removed as part of a refactor in PR #430.

Is get_account_data() the replacement for the old get_accounts()?

[gerber55555]

@nickodell Yes I got it working, I pulled the same branch and commit as you. And it seems like get_account_data() is the replacement for get_accounts(), which provided the data I needed. I'm not sure why it was changed either.

[mrooney]

@burkematthew do you think it would make sense to write a wrapper method so folks can still use get_accounts()? Backwards imcompatible changes seem fine if super helpful, but this might confuse a bunch of folks? Or maybe we just need to document it in the CHANGELOG.

[burkematthew]

@mrooney I missed making the changes in the README, which is part of the confusion.

One of the reasons I felt it was helpful to break the names is that each method has different input and very likely different outputs. By "breaking" the old method, we force users to take a look at the new input and the structure of the new output instead of them going through trial and error on what changed to make it break.

That being said, if the consensus is wrappers would still be beneficial, then that's something we can do.

[nickodell]

@burkematthew Thanks, that makes sense. If the data being returned is changing, then maybe it doesn't make sense to provide it under the same name.

[burkematthew]

@nickodell the data is obviously pretty similar but there are definitely differences.

[mrooney]

@burkematthew oh right, if the data is different, I like that approach. As long as it is documented in the 2.0 changes that sounds great!

[burkematthew]

@mrooney I'll do some fixing up of the README and also make sure that it's addressed in the release summary.

[burkematthew]

Morning everyone! I just opened #462 to fix the README issues we discussed and then also do a more explicit callout in the CHANGELOG.

[mrooney]

Apparently there is a new version of Mint that they are working on to support. If you pull the repo and build it locally you will be able to use it. Keeping this issue open until new version is released however.

Thanks, glad you got it working! We consider an issue closed once a fix has been merged to main, so I'll close this out for now, but please let me know if you are running into any other issues.