-
Notifications
You must be signed in to change notification settings - Fork 278
What to do with tuf/exceptions before 1.0.0? #1729
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
Comments
I don't have a strong opinion here, but I tend towards option 3. Also, I wonder if we still want to keep the |
(changing title, I assume this was intended) |
In #1725 I have tried implementing option
My personal feelings are against moving the code anywhere for the following reasons:
@lukpueh and @jku can you see #1725 and #1734 which seem related to the current discussion. |
We have decided in #1725 that we would place the new exception file in |
Description of issue or feature request:
Currently, we are using
tuf/exceptions.py
to store client and repository exceptions both for the new and old implementation.After we drop the old code we will have to keep the exceptions from
tuf/exceptions.py
or move them to somewhere else.Some of the options I and @jku come up with are the following:
tuf/api/exceptions.py
storing all exceptions needed from the client, metadata API, and future repository code (see #17256). Then when the old code is dropped thetuf/exceptons.py
will be removed as well.tuf/exceptions.py
and just remove the old exceptions.py after we remove the old code. This will require linting the file and changing the docstrinsg (see Start linting tuf/exceptions.py with all linters #1721)tuf/api/
with repository side and metadata API exceptions and one intuf/ngclient/
where we will store the exceptions for the ngclient. Removetuf/exceptions.py
together with the rest of the old code.Option
1
or2
seem easier to change with less code, but option3
will provide better encapsulationThe text was updated successfully, but these errors were encountered: