switch from py.iniconfig to iniconfig

[RonnyPfannschmidt]

As part of removing pylib

See also #7259

[bluetech]

My preference is to copy over the implementation to pytest, instead of depending on the iniconfig package. This is because:

• It is an internal dependency AFAIK.
• It is small (~100 lines).
• Python dependency management is still... lacking.
• By having it in tree we can adapt and adjust it freely without backward compat concerns or cross-project synchronization overhead.

[RonnyPfannschmidt]

Personally I'm strictly opposed to own internal copies of libraries /structural components,

As pypa/pip#988 is going to be resolved in a reasonable time frame I'm actually working on taking specific logic components out of pytest and to foster more sharing among test runners

[bluetech]

My experience with npm-style micro dependencies is very negative. At work, our gigantic Django-based server has 50 transitive dependencies (include dev dependencies). The JS frontend has about 3000. I hope Python doesn't go that way.

[RonnyPfannschmidt]

i'm happy to go with some type of automated vendoring apporach, i'm not going to keep custimized internal copies of things that should be external and shared

i agree that npm is a extreme

i also believe that a good choice in granularity + vendoring tooling could make things transitively better

[nicoddemus]

Given the discussion should we go ahead with #7292? I think so, because even if we decide to vendor it later, part of the work is done already.

[bluetech]

My preference is to integrate iniconfig into pytest, and allow changes like a regular module, i.e. not vendor or depend on it. I'd like to be able to make it conform to our code style, linters, add type annotations, fix bugs, refactor and add new features directly, etc. Also, according to this the package isn't used much by other projects, and is maintained by Ronny, so it will essentially be "owned" by pytest anyway...

But just to be clear, if both @nicoddemus and @RonnyPfannschmidt think it's a good idea then I'm perfectly fine with that (the PR itself looks good), I'm just trying to advocate my position :)

[RonnyPfannschmidt]

It's used by tox via pylib, and based on the experience with py.code integration I am severely opposed to integration of any other lib, i rather want to focus on extraction of more functional components rather than having hidden internal apis

[The-Compiler]

I'm a bit late to the party, but is there a good reason that pytest really needs a hand-rolled ini-parser rather than configparser in the Python stdlib? Didn't notice this before the 6.0 release, but that additional dependency probably caused quite a bit of additional work across various Linux distributions packaging pytest.