Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Override line-length for subdirectories #1370

Closed
aklajnert opened this issue Apr 29, 2020 · 5 comments
Closed

Override line-length for subdirectories #1370

aklajnert opened this issue Apr 29, 2020 · 5 comments
Labels
C: configuration CLI and configuration T: enhancement New feature or request

Comments

@aklajnert
Copy link

Currently, black allows changing the line length globally via pyproject.toml or with the --line-length argument. This setting is global for the whole directory tree.

In my project, I have a docs/examples directory, which contains python files, that are shown in the documentation by using the literalinclude directive. While for most of the project the global line length setting (100) is fine, for the examples it's too wide and requires the horizontal scroll bar to display the code samples.

I've tried to add another pyproject.toml file in the docs/examples directory, but it is respected only when I'll execute black from that directory. It's hard to use it from pre-commit hooks.

Is there any way to override the line length for subdirectories?

@aklajnert aklajnert added the T: enhancement New feature or request label Apr 29, 2020
@zsol
Copy link
Collaborator

zsol commented Apr 29, 2020

You can specify the location of a config file via the --config command line option, if that helps.

@aklajnert
Copy link
Author

A bit. I mean, I can construct pre-commit hooks for that, but I still can't run single black . command to correctly format everything.
It would be nice to automatically load and respect pyproject.toml files in the subdirectories that override certain settings, or allow overrides in the root pyproject.toml similar to how mypy:

[mypy]
python_version = 2.7
warn_return_any = True
warn_unused_configs = True

# Per-module options:

[mypy-mycode.foo.*]
disallow_untyped_defs = True

@JelleZijlstra JelleZijlstra added the C: configuration CLI and configuration label May 30, 2021
Shivansh-007 added a commit to Shivansh-007/black that referenced this issue Oct 7, 2021
Woohoo! "Big" convifg overhaul and a bit of restucting of code in the
black/__init__.py file. Mainly shifting all the "reformating" logic to a
separate function to increase the readability of code in the click CLI
function. You can go through the code in the commit, code should be self
explainatory, though I still need to update the documentation of the
code and this feature.

I haven't aimed at bringing new tests in this commit, if required, I
could do that and this rather fixes the tests to work according to the
change I have done in this commit.

Summarizing the changes:
- Now, you can support file/module specific configuration in the
  pyproject.toml config under the section of `[tools.black-module]`. I
  have added a separate "key" for the modules as according to the
  current code when the module name could clash with a config argument.
  For example `[tools.black.src]` would clash with `SRC`.
- Module specific configuration can only some arumgents which are listed
  under a global constant in `config.py` and should agree with the
  typehint present on them in the class variables, the logic for this
  fuctionality can be seen in `cast_typehint` function of `config.py`.
  At someplaces I have ignored MYPY errors so as I couldn't change the
  configuration since they were being used for typing.
- Added a new class for storing all the parameters, the order of the
  arguments is as follows:
  * Read global pyproject.toml/specified config config.
  * Read module specific config, which would take the none specified
    arguments from teh global configuration.
  * If value specified through click options/arguments it would be
    overwritten, this won't happen if the default value of the option is
    taken.
  * Tada!

Closes psf#1370
@JelleZijlstra
Copy link
Collaborator

There's been some discussion on the linked PR that's really about whether we should do this at all. That's more appropriate to the issue, so I'm bringing it back here.

@felix-hilden brought up that we may not want this at all as it doesn't go well with our general stance to minimize configurability. I'm sympathetic to that argument, but I do find @aklajnert's use case above compelling.

@felix-hilden
Copy link
Collaborator

I tend to agree that line length shouldn't be that big of a deal, since the presented use case is solid.

@JelleZijlstra
Copy link
Collaborator

Since this hasn't been a common request and it would complicate our internals, I'm now inclined to reject this enhancement request. We can revisit that decision if we get more use cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: configuration CLI and configuration T: enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants