remove tomlkit from poetry-core

[dimbleby]

Continuation of python-poetry/poetry#6562, this removes use of tomlkit from poetry-core altogether, replacing it with tomli (and tomli-w in unit test).

tomli is smaller, faster, more stable, and being adopted by the standard library. poetry-core has no need of the extra features that tomlkit brings.

see also python-poetry/poetry#6616

[mkniewallner]

I suppose that this would resolve python-poetry/poetry#6201, since we would now end up with a proper dict, and obviously make #445 unnecessary.

[dimbleby]

python-poetry/poetry#6562 alone would be enough to deal with python-poetry/poetry#6201: tomli-w will not write extra indents to the lockfile.

[neersighted]

This looks good to me, but I'm not sure how best to handle it release-wise. poetry-core moving fast is all fine and good until Poetry 1.2 experiences wild changes in a patch release that breaks plugin compatibility.

Maybe we should start a new branch of poetry-core for 1.3 -- however that's a lot more effort and we'll have to change our test strategy + maintain more moving parts.

[radoering]

Why should we do it the other way around here (compared to poetry)? If we can't use main for poetry 1.2 anymore, shouldn't we just create a branch from the last core version included in poetry 1.2 (currently 1.2) and only backport changes that are necessary for poetry 1.2?

Alternatively, we could hold back this PR until poetry 1.3 is in sight. Not sure if that's better...

[dimbleby]

bump the version number, update the changelog, publish. No problem.

In the relatively unlikely event that poetry-core needs a 1.2.1 release, go back and create a 1.2 maintenance branch.

(Overlapping comments, I think this is more or less what radoering said too)

[neersighted]

It's more the want to set up backport infrastructure and triaging every PR as a possible regression fix that concerns me, but I suppose volume is much lower than core, so we could just cross that bridge when we come to it.

[dimbleby]

IMO more or less nothing should ever be backported, just release a new version and tell folk to upgrade if they want the fix. Rare exceptions exist eg perhaps that time that the pypi API changed and left poetry completely broken, but they should be rare.

Then the fun of backporting and maintaining multiple branches pretty much goes away.

That doesn't seem to be poetry's preferred approach though. Perhaps a conversation for another time.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[github-advanced-security]

You have successfully added a new SonarCloud configuration ``. As part of the setup process, we have scanned this repository and found no existing alerts. In the future, you will see all code scanning alerts on the repository Security tab.

[dimbleby]

I see there's PEP-621 related activity happening, very cool.

That's surely going to have conflicts with this one, it would be good to take a decision on this one way or the other so as to avoid unnecessary work later.

[dimbleby]

ugh, what's going on in the windows tests? looks like tomlkit is writing invalid toml with consecutive carriage returns?

[dimbleby]

oh no, I see, it's related to this in the unit tests

https://github.com/python-poetry/poetry/blob/71b3d6e030c879f0b4b8e3a08eac2b38a402b6bd/tests/console/commands/test_add.py#L940-L942

which indeed will transform \r\n into \r\r\n

[dimbleby]

(but I don't understand where the additional carriage returns are coming from and I am somewhat hampered by the lack of a windows development environment)

[radoering]

Seems to be a builtin weirdness:

Path(r"C:\temp\test.txt").write_text("test\r\n")

results in "test\r\r\n"

Maybe I can take a closer look tomorrow.

[dimbleby]

Ah, I see, thanks. I withdraw my default blame-tomlkit reaction!

So the trick presumably is to specify newline="" - which is exactly what tomlkit does https://github.com/sdispater/tomlkit/blob/18a527758bfa3f8fe65e2f45f61df42f2f5af0c1/tomlkit/toml_file.py#L57-L58

pathlib's write_text() doesn't get that parameter until python 3.10, so that can't be used here.

Now fixed over in the corresponding poetry MR.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information