Use black for loading black config

[jeremyheiler]

PR Summary

Fixes #1949

This changes how black configuration is loaded. Instead of looking for
pyproject.toml directly, use a black to load the configuration in the
same way the black CLI would. This allows for other configuration
files to be considered, such as ~/.black or ~/.config/black.

PR checklist

Please make sure that the following things have been addressed (and check the relevant checkboxes):

• Commits respect our guidelines
• Tests are passing properly (see here on how to run Elpy's tests)

[gopar]

Hey! Many thanks for the PR :)

Looks like black.files did not always exist until:
psf/black@f2ea461 (which was earlier this year)

The function find_pyproject_toml was instead in black/__init__.py. So for projects using an older version of black, this would break what we have for them :/

I do like the idea of letting black find the config file instead of whats happening in right now.

ASK:
Can you make a check that find_pyproject_toml exists in black and if it doesn't then import black.files? I feel this will less likely break things (ah the joys of trying not to break anyone's working elpy config :)

[jeremyheiler]

Can you make a check that find_pyproject_toml exists in black and if it doesn't then import black.files? I feel this will less likely break things (ah the joys of trying not to break anyone's working elpy config :)

Yes! I was actually thinking about this last night as I was falling asleep.

[gopar]

Once the changes are implemented, I'll gladly merge!

[jeremyheiler]

All set!

[gopar]

Did find_project_toml not exist before this version?
If it didn't then we should have find_project_toml = None as an else branch so that we don't throw an error later down the road since find_project_toml won't be defined.

[jeremyheiler]

Yes, it was introduced in May of 2020, and the next release was in August 2020. I'll set it to None in the else block. My original implementation defined a custom find_pyproject_toml in the else block, but due to the function signature, it was more complex than adding a check at the call site.

[coveralls]

Coverage decreased (-8.7%) to 82.863% when pulling b3be4b5 on jeremyheiler:black-config-lookup-fix into 8d0de31 on jorgenschaefer:master.

[gopar]

Merged. Thank You!

[posita]

This probably needs to be reverted or fixed. I'm pretty sure it is the root cause of #1955, which is currently being experienced in elpy-20211211.2248 on Melpa.

[gopar]

@jeremyheiler do you have some time to look into this for a potential fix?

[posita]

I think this may be the root cause of #1955. It looks like (at least with black==21.12b0 that find_pyproject_toml will return None if it can't find "pyproject.toml" in directory.

Calling os.path.exists(pyproject_path) then equates to os.path.exists(None), which will raise an exception:

>>> import os.path
>>> os.path.exists(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/MacPorts-20211130/Python.framework/Versions/3.9/lib/python3.9/genericpath.py", line 19, in exists
    os.stat(path)
TypeError: stat: path should be string, bytes, os.PathLike or integer, not NoneType

[posita]

I think #1955 can be fixed by changing this line to:

if toml and pyproject_path and os.path.exists(pyproject_path):

This seems to cure the problem in my hand-testing of both in 0803e76 and master, so I think it should do the trick. 👌

[posita]

@jeremyheiler do you have some time to look into this for a potential fix?

Yup! See this comment for a recommendation. I'm pretty sure that should do it. UPDATE: PR is up (#1956), but I could use help testing it.

You'll have to forgive me, past that, though. I don't have much experience with elisp or elpy's test mechanisms to formulate an automated way to repro this, so I think that's about as useful as I can be in this context (at least right now).