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

[feature-request] Config inheritance #1055

Closed
smackesey opened this issue Dec 5, 2022 · 4 comments · Fixed by #1219
Closed

[feature-request] Config inheritance #1055

smackesey opened this issue Dec 5, 2022 · 4 comments · Fixed by #1219
Assignees
Labels
configuration Related to settings and configuration

Comments

@smackesey
Copy link

smackesey commented Dec 5, 2022

In monorepos, it can easily happen that some section of the codebase needs to maintain consistency with the rest of the code but vary in one dimension. For example, in Dagster we use a line length of 100, but shorten it to 88 for our docs-snippets package, which includes code snippets that are incorporated into built docs. The shorter length is to ensure readers don't need to scroll horizontally when reading a code block in the browser.

We're currently maintaining a separate pyproject.toml file in docs-snippets where we duplicate most of the configuration in our root pyproject.toml for black and isort, just so that we can change the line length. This is because neither of these tools offers any mechanism I'm aware of for config inheritance, which would allow only overriding specific settings.

But it would be great to have-- for ruff, it might look something like this:

# pyproject.toml (root)

[tool.ruff]

line-length = 100
# ... rest of ruff config

# examples/docs-snippets/pyproject.toml

[tool.ruff]

extends = "../../pyproject.toml"  # reads settings from root pyproject.toml
line-length = 88

That's just a suggestion, I haven't thought about how best to implement this-- but some generic extension/inheritance mechanism for config would be useful. Eslint might be a good place to gain inspiration.

@charliermarsh charliermarsh added the configuration Related to settings and configuration label Dec 5, 2022
@smackesey smackesey changed the title Config inheritance [feature-request] Config inheritance Dec 5, 2022
@charliermarsh
Copy link
Member

Yeah, agree with the issue summary. (The discussion around presets would also be relevant here: #809.)

I'd like it to be explicit and opt-in, like ESLint's extends, rather than doing anything implicit based on the filesystem hierarchy.

The trickiest part is that we'd then have to use different settings for different files within a single ruff execution (at least, I think that's how ESLint works). Right now, we resolve the single project root, resolve the settings, then lint all files with those settings; but if we support configuration inheritance, we may have to resolve different settings for different subtrees of the filesystem.

@charliermarsh
Copy link
Member

By the way: thanks for all the thoughtful and well-written issues. I also realized this morning that you wrote the Dagster article on type migrations, which I enjoyed a lot. Great to have you hanging around the Ruff repo.

@smackesey
Copy link
Author

Thanks-- yeah I've done a lot over the past 24 hours assessing ruff and trying to port Dagster OSS. Almost at the finish line. Your selling point of extreme speed is 100% accurate, I'm pretty excited to get linter editor feedback as instantly (even faster really) as the type-checking feedback provided by pyright/pylance. Also very nice to have something so actively developed-- that aliased import config option you added 1 hour after I requestedi it last night would've probably taken a year to get implemented in isort. Thanks for your hard work here!

@charliermarsh
Copy link
Member

This is going out in v0.0.178. For now, at least, it's explicit via extends.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
configuration Related to settings and configuration
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants