Black: Refactor black.py into a black/ python package

[vdwees]

A lot of packages I use organize the code into directories with lots of small files. Black stores almost all of its logic into a single, massive file: black.py Is this just for historical reasons, or is there a technical reason behind this?

[JelleZijlstra]

I think @ambv liked it this way. We'll probably move to a package at some point.

[ambv]

Originally it was under 2k lines, perfectly fine for a single file. Having it like this had advantages in search while editing, import time, and ease of packaging and testing alternative versions.

Now the size crept up quite a bit. Soon it will be time to unbundle the file.

[cooperlees]

Now the size crept up quite a bit. Soon it will be time to unbundle the file.

Should we organize a Zoom or something to discuss a design with all maintainers all agree? We could start a Google doc for everyone to comment on.

• I'm happy to lead this refactor with some of the spare time I have

[ambv]

Sounds good, @Cooper! Keep in mind this will be disruptive for open pull requests and we should keep our API users able to import names from "black" just like now.

[cooperlees]

Ok, so I've made a doc with 'a' way forward on the refactor of black.py to black/. I've shared it with each core dev of Black and have given access to comment etc. - Lets take the discussion there.

tl;dr - git mv black.py black/__init__.py and then refactor is my plan.

Fore everyone else:

Read Only Link:
https://docs.google.com/document/d/1iPwHdc1JSn0inNiOVRakTXueK4bE6Arffhw0KeTMBLY/edit?usp=sharing

Please feel free to comment here your thoughts and ideas for the refactor. I'll try be your voice on the doc and end decision.

[hugovk]

Sounds sensible to restructure the directories first, and then let the refactoring begin.

How about moving to src/black/ rather than just black/?

• https://hynek.me/articles/testing-packaging/
• https://docs.pytest.org/en/latest/goodpractices.html#choosing-a-test-layout-import-rules
• https://blog.ionelmc.ro/2014/05/25/python-packaging/

[cooperlees]

I'm down to use src/ if more people are partial to it.

I do have a project I look after with a src directory. When I inherited bandersnatch years ago I wondered why the src/ dir was used. Reading these 3 links has identified some reasons why, but I've never seen all these benefits through my experience with bandersnatch.

[zsol]

I support the src directory

[cooperlees]

Ok - With @ambv also on board for src/* I will attempt the PR one day soon.