Learn more about these different git repos.
Other Git URLs
The same way, that we currently store a reference to the response object (result.__response__), we might want to store a reference to the proxy object.
result.__response__
from copr.v3 import Client client = Client.create_from_config_file() build = client.build_proxy.get(123) # Imagine this line done internally in the `build_proxy.get` method # Actually, by all proxy methods build.__proxy__ = client.build_proxy
This will mainly allow one thing - Obtaining a new version of an object, based just on itself.
build.__proxy__.get(build.id).id 123
There are many practical applications of this, which can be implemented by us or third-party.
wait
build_proxy
refresh
I am not saying, that we can't live without these, neither that I want to implement them (except for the first one). But it might be useful for some people / some use-cases.
Why __response__ object is not enough? In the particular example shown in this issue, it is possible to do
__response__
import requests from copr.v3.requests import munchify # Not part of the API session = requests.Session() result = session.send(build.__response__.request) munchify(result)
but this approach is not versatile enough. It works only when the original munch was returned by a get method. If it was returned from e.g. create_from_url, it will create a new build on each call, which is not the wanted behavior.
get
create_from_url
Do we want the result.__proxy__ reference? Is there any reason why not?
result.__proxy__
Metadata Update from @frostyx: - Issue tagged with: API
Metadata Update from @frostyx: - Issue tagged with: RFE
Modified in PR#436
Merged, I am closing this issue.
Metadata Update from @frostyx: - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.