poetry-core
poetry-core copied to clipboard
remove Package.with_python_versions()
remove with_python_versions() on the grounds that
- it has had no callers since more than two years now https://github.com/python-poetry/poetry/commit/2433e0e7007edddf6c74635aae5fc4b3dfdcc617
- the naming convention
with_
(orwithout_
) 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
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 withTrue
-
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
- If any plugin was relying on this they can always reconstruct it using the removed code
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