Rename repository modules

[b-kamphorst]

Relates-to: #3155

• Added tests for changed code.
• Updated documentation for changed code.

Follow-up of #6669 regarding the proposed renaming of modules in poetry/repositories.

A subsequent PR for poetry-plugin-export is in preparation: python-poetry/poetry-plugin-export#151.

[b-kamphorst]

@neersighted let's make this fly. For now, I've added DeprecationWarnings that indicate support until poetry v1.4.0 (as to not be breaking for the next poetry minor release, 1.3.0). I noted that the deprecation warning for the poetry.core.semver.version:Version import did not state a version, but it might be good to do so.

You also mentioned the desire for a RepositoryName type that represents a normalized name. My (ugly) attempt at doing so broke the plugin and would be less ugly if rooted in poetry-core. Not sure if we want to pick this up, and if so, where.

Looking forward to your thoughts.

[radoering]

I propose to divide the rename and the deprecation into two commits as done in python-poetry/poetry-core#482. That way, it's easier to follow changes in git history and doing rebases of PRs changing code in one of the renamed modules.

[radoering]

And it simplifies the review. 😉

[b-kamphorst]

I propose to divide the rename and the deprecation into two commits as done in python-poetry/poetry-core#482. That way, it's easier to follow changes in git history and doing rebases of PRs changing code in one of the renamed modules.

Done!

[radoering]

Is there a reason for not having a deprecation warning for cached? (And for the exclamation mark in the commit message. refactor!: rename cached to cached_repository?)

As for the wording of the deprecation warning (if we want to add a "scheduled for removal notice" and if it will be 1.4), I'll leave that decision to @neersighted. Afaik we don't have a schedule yet for how long we keep deprecated code.

[b-kamphorst]

Is there a reason for not having a deprecation warning for cached? (And for the exclamation mark in the commit message. refactor!: rename cached to cached_repository?)

Not really -- I hoped that this was used only internally and therefore we may not have to remain compatible. But that was just guessing so I'll change it (probably tomorrow). I guess in general with Python it is not quite clear what the API is -- harder to know what you can change without issues to others.

As for the wording of the deprecation warning (if we want to add a "scheduled for removal notice" and if it will be 1.4), I'll leave that decision to @neersighted. Afaik we don't have a schedule yet for how long we keep deprecated code.

If this is part of the public API, I'd expect deprecation in a major release. But I'm not sure how the poetry team applies versioning. We can leave it open but I think it is nice to at some point (timely) inform users when it is completely removed. Looking forward to your suggestions.

[b-kamphorst]

@radoering, I've added the deprecation warning for poetry/repositories/cached. I think all that is left to finalize is the content of the warning message depending on your and @neersighted's thoughts?

[radoering]

We decided that the deprecation warnings are fine as they are. I just noticed a test that seems to be duplicated (see separate comment). Apart from that I think this PR is ready to merge.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.