You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One thing that I've considered a couple times is the use of the hardcoded category values for stdlib and first party modules. Specifically for cases where the user potentially does the following in their project config:
The future, stdlib, and first-party detection, all hardcode categories that wouldn't be in the configured category list, and I'm not sure how that ends up working in the sorting system, or what the correct way to deal with this would be (other than more configuration options that I don't think we want). Maybe we need to do something like known[module] = CAT_FIRST_PARTY if CAT_FIRST_PARTY in config.categories else config.default_category. But maybe something that makes that easier rather than repeating that everywhere? 🤷
The text was updated successfully, but these errors were encountered:
If there was an elegant PR to support this, I'd be fine with fully customizable mapping. I think it's a lot of complexity that most people don't need, and for now would favor expanding this pattern of just complaining loudly to cover other validation issues:
I think I just encountered this - basically would like a way for all imports to have one block, and have block separations be made manually only. I would like for blocks to be extremely intentional and vital to how the code runs, not just having them for stylistic reasons.
After reading the docs my userland self came to the conclusion to try variants of the following to get it,
The proliferation of blank lines is an issue that I plan to fix for version 1.1 — see #163 for that. This issue is specifically around handling non-standard configurations, because µsort hardcodes a couple category names in its handling of stdlib and relative imports, and then breaks if users have explicitly defined a set of categories that don't include those expected values.
One thing that I've considered a couple times is the use of the hardcoded category values for stdlib and first party modules. Specifically for cases where the user potentially does the following in their project config:
The future, stdlib, and first-party detection, all hardcode categories that wouldn't be in the configured category list, and I'm not sure how that ends up working in the sorting system, or what the correct way to deal with this would be (other than more configuration options that I don't think we want). Maybe we need to do something like
known[module] = CAT_FIRST_PARTY if CAT_FIRST_PARTY in config.categories else config.default_category
. But maybe something that makes that easier rather than repeating that everywhere? 🤷The text was updated successfully, but these errors were encountered: