-
Notifications
You must be signed in to change notification settings - Fork 275
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove "legacy code" #1745
Comments
I prefer keeping
Fine by me (although I don't feel a strong need: imports look fine to me now). If we do this I would suggest we consider keeping the code where it is though (for git reasons) and solving the problem with clever imports. |
Are we sure we won't lose the Git history if we do this? |
To me it's not about discoverability, but more about the baggage of the "previous generation"-client the name refers to, which I think is unnecessary. The "error on import argument" is fair, although I don't think this will be a problem in practice.
Isn't part of the python zen to not be clever with imports? :) Also, an import alias wouldn't really solve the problem that the repo has an unnecessary subfolder. So I'd either rename or leave as is. And I don't think git history is a problem, because many git features work across renames out of the box, and those that don't can usually be worked around when you know that there was a rename at some point, which can be communicated in the renaming commit's message. |
You make a valid point ... but as an example of something not-too-clever I think we aren't using |
After a meeting with @jku and @lukpueh it was decided that there is no need to do renames.
Using
There were no strong preferences between using using |
The recently released v0.20.0 was the last release to include the legacy implementation. In preparation for v1.0.0 it is time to actually say farewell to the legacy implementation. Here is a (likely non-exhaustive) list of related tasks:
ngclient
->client
IMO the name
ngclient
makes most sense in relation to the "old" client and so will lose its meaning after the old client has gone, at least after a whileapi.metadata
->metadata
IIRC the api directory was a bit of a crutch to develop new code alongside legacy code without mixing them up, which we won't need after removing the legacy code. IMO api should be designated by other means, e.g. on RTD
The text was updated successfully, but these errors were encountered: