remove Package.with_python_versions()

[dimbleby]

remove with_python_versions() on the grounds that

• it has had no callers since more than two years now python-poetry/poetry@2433e0e
• the naming convention with_ (or without_) on the package is nowadays being used to mean "a clone of the package with (or without) this thing", this collides with and confuses that
• it's bizarre anyway

[radoering]

I'm a little torn whether we should deprecate it before removing because there might be some plugin out there using it.

[dimbleby]

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.

[dimbleby]

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

[dimbleby]

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.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[radoering]

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)?

[dimbleby]

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

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[Secrus]

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

[dimbleby]

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

[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