provide a way to mix stdlib and third party libraries in one section

[mmerickel]

stdlib dependencies and third party dependencies are indistinguishable in many cases and I would like to sort them into the same section, separately from local dependencies.

For example, enum is stdlib on Python 3 but third party on Python 2 when using a backport. The order of the sorting is different based on whether I run isort using Python 2 or Python 3.

It's possible to fix this with known_standard_library=... but this is tedious to maintain if I want to sort every single third party library along with stdlibs.

I'd propose some form of + syntax allowing me to specify sections=FUTURE,STDLIB+THIRDPARTY,FIRSTPARTY,LOCALFOLDER.

Even if my rationale is not interesting, I think the syntax is very useful to be able to combine a couple sections which is not currently possible. You can specify a line break or not between sections, but there's no current way to actually just combine them.

[fgblomqvist]

I think this kind of combine syntax is really intuitive and a great feature addition. I usually just sort my imports like this: sections=FUTURE,STDLIB+THIRDPARTY,FIRSTPARTY+LOCALFOLDER. Right now, with the no_lines_before option, it just smashes the two sections together (e.g. no combined sorting), which doesn't look right.

What's the status on a feature like this? Does any maintainer have any opinions? Is it open for PRs? Sad to see it just sit here all alone.

EDIT: Actually, this issue is very similar to/same as #447. They both essentially want a way to merge sections.

[mmerickel]

FWIW I'm having success by just dropping the STDLIB section and making THIRDPARTY the default section. I then annotate my specific package as known_first_party. I think the + syntax would still be nice though.

[settings]
# ... snip ...
sections=FUTURE,THIRDPARTY,FIRSTPARTY,LOCALFOLDER
default_section=THIRDPARTY
known_first_party=myapp

[timothycrosley]

Closing as duplicate of 447

[epage]

@timothycrosley this isn't a dupe of #447 since that was resolved with no_lines_before and this issue specifically calls that out as being insufficient

(posting this in hopes that this issue can be re-opened rather than me going and creating yet another issue)

From @mmerickel

You can specify a line break or not between sections, but there's no current way to actually just combine them.

From @fgblomqvist

Right now, with the no_lines_before option, it just smashes the two sections together (e.g. no combined sorting), which doesn't look right.

My use case is that I am running isort across an entire monorepo and isort is running in a dedicated / clean venv so it cannot tell first party and third party. I run into problems when other users have a dirty global site-packages. I've resolved most of this with section_default=THIRDPARTY but there are additional corner cases I'm running in to.

[mmerickel]

Agreed it's not a duplicate. The solution I mentioned above is what we are using in Pyramid and we're pretty happy with it. @epage what corner cases are you referring to? I haven't needed to do any work outside of a virtualenv in years, not even one linked to system site packages.

[epage]

The main issue is setting known_first_party is impractical in my situation. I'm working with a monorepo and we don't want to have to maintain configurations per package that diverge over time nor try to keep a central configuration up-to-date with all of the package names.

[mmerickel]

That makes sense, I don't know how to resolve that generally to differentiate between local packages and system packages without maintaining a list.

I solve this at $work in our monorepo by placing all the packages into the same namespace (namespace packages), and tagging that namespace as known_first_party.

[epage]

I don't know how to resolve that generally to differentiate between local packages and system packages without maintaining a list.

Overall, I'm fine mixing first-party and third-party, its a small price to pay to get isort. The problem is my hacks to mix them aren't complete enough so depending on how an end-user has configured there machine, things might get sorted differently.

[timothycrosley]

Hi @epage I'm sorry you've encountered issues using isort around this!

In my opinion, @mmerickel's solution is the right one, and I know it is used by some major projects. You can combine any sections, simply by correctly setting the known_ sections, so I haven't felt a compelling case for complicating the project further. If you want to combine first-party and third-party, you just need to do:

[isort]
known_third_party=[]
src_paths=[]

And everything will end up in the third_party section.

(posting this in hopes that this issue can be re-opened rather than me going and creating yet another issue)

I appreciate the goal to reduce the number of issues. I will say, I do as a general rule, encourage new issues to be raised, since I get a lot of email and am not the only maintainer. isort only has 20 open issues, but > 800 closed ones. It is much more likely that comments in open issues will be actioned, and not forgotten simply because of communication overload!

The main issue is setting known_first_party is impractical in my situation. I'm working with a monorepo and we don't want to have to maintain configurations per package that diverge over time nor try to keep a central configuration up-to-date with all of the package names.

What version of isort are you using? If you are using 5.x.x there is a good chance everything will work correctly simply putting by listing out the src_paths of your monorepo with an isort config at the root. If not the solution above can be used. If you are not using 5.x.x see the upgrade guide here: https://pycqa.github.io/isort/docs/major_releases/introducing_isort_5/

If these steps don't help resolve your issue, please feel empowered to create a new one

Thanks!

[epage]

[isort]
known_third_party=[]
src_paths=[]

I'm assuming that is not literal but that I should be populating those fields with all my source and third party (since loading that config fails).

Digging into it, it looks like

[isort]
src_paths=

is accepted by isort and does prevent any src paths from being searched.

It also looks like all the fancy finders have been removed so third-party is only determined by the default section and known_third_party.

So I think that should cover my use case in a maintainable way (since the alternative involved maintaining an explicit list of either source or third party in a constantly evolving repo is adding more friction to the process and could tip the balance in to dropping isort).

[timothycrosley]

@epage exactly right! I did initially intend to make something you could literally copy, but failed in my at the time sleep deprived state - I'm glad you figured out the correct config, and listed it here for future users who run into this issue.

So I think that should cover my use case in a maintainable way (since the alternative involved maintaining an explicit list of either source or third party in a constantly evolving repo is adding more friction to the process and could tip the balance in to dropping isort).

🎉 I'm so glad that will work for you! The other thing that can work in a monorepo is just putting the .isort.cfg in the root of the repo, and then it will pick up all source paths automatically from there. But, this is highly dependent on how your monorepo is set up. Either way, maybe not worth risking the good thing you've got going with the updated config.