Closed jakkdl closed 1 year ago
What's the problem with just using shed
? Probably obvious, but I really like having a single standard configuration across all my projects.
Could the issue be addressed by disabling shed
for some test files and only using black
there?
The current issue is very specifically that I want to disable autoflake
removing pass
for autofix_files
. The particular checks I want to run for those files I don't fully know, and while just running Black would probably be fine, I would prefer to default to running everything on the semi-generated code to alert me of any possible weird stuff going on asap, so I can fix it or be aware of the limitation. I could maybe also/instead stop blanket disabling flake8 for eval_ & autofix_files.
But given how much I've fought with shed in the past with eval_files
, and even occasionally with e.g. the imports in visitors/__init__.py
, I personally prefer to have a bit more control than shed currently allows. (but definitely not as much as e.g. isort, that's just a crazy amount of config :sweat_smile:) So yeah, that's why I've asked for any ways of making marginal changes to shed's behaviour.
It's also sometimes been frustrating to track down why a diff is generated, when shed modifies a file I either have to debug, or manually run the underlying tools, if/when I want to know what tool it is that generated the diff. Sometimes this is for requesting bugs/features in those tools/shed, or when I want to know whether to add # noqa
, # isort: skip
and/or fmt: off
.
tl;dr, we could def go back to shed if you insist - but I do find it frustrating/limiting at times, aside from the current autoflake pass
problem which prompted this.
Split out shed for more granular control of the underlying tools, also added auto-formatting for yaml&toml and other minor config changes.