There's lots of crud in poetry-core that it's desirable to remove (I have similar queued up that I'll submit when things quieten down / I have a large enough collection). Going through deprecation periods for everything is going to get tedious.

IMO: clean up at will, note it in the changelog, do major version bumps if we think we've made possibly-breaking changes. I see nothing to be afraid of in this package going 2.0 or 10.0 or even 50.0.

Added a couple more removals to this MR, probably might as well discuss / make a decision for them all in the same place

• EmptyConstraint.matches() should be uncontroversial, who knows what this was intended for but anyone who was relying on it can replace with True
• python_marker on packages may be more interesting.
  • If any plugin was relying on this they can always reconstruct it using the removed code parse_marker(create_nested_marker(...))
  • from the point of view of poetry / poetry-core this is a great candidate for removal: that's quite a lot of work to do for every package, in code that's had more than its share of bugs, so if it's not needed then that's super news

Actually the export plugin is an example of a project that relies on the python_marker, but only for the root package.

I'm pretty neutral about whether to leave it on the root package (reasoning about cost can't matter for a single package), or have the export plugin work it out itself from the root python_constraint. Or we could just keep python_marker everywhere. Views welcome.

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

I'm pretty neutral about whether to leave it on the root package (reasoning about cost can't matter for a single package), or have the export plugin work it out itself from the root python_constraint. Or we could just keep python_marker everywhere. Views welcome.

We could make it a cached_property. Unfortunately, cached_property is not available for Python 3.7. We added a backport package in poetry. We probably had to vendor it here (or just copy https://github.com/penguinolog/backports.cached_property/blob/1.0.2/backports/cached_property/__init__.py into utils/_compat.py)?

Unless profiling shows otherwise, I doubt that there's enough of a performance issue to justify adding complication.

My goal in deleting code is quite the opposite of that: I want to remove complication.

• This is an area that has historically been buggy. No code = no bugs!
• But mostly: it's a burden for the human reader. Whenever I get into one of those bugs that requires me to figure out what the solver is doing, I could do without having to worry about whether the python_marker is a thing that even matters

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

Now that we dropped Python 3.7 and cached_property availability is not an issue, are there any more blockers here?

python 3.7 and cached_property are irrelevant here: per my last I have no intention of making code more complicated, the goal is to delete it.

this is blocked only by a maintainer agreeing that that is a good idea

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

@dimbleby would you rebase? With 2.0 coming we are introducing breaking changes anyway, so we might as well break this too

By the way, I renamed the PR because Package.with_python_versions() has already been removed in 01b58ea so only Package.python_marker is left.