Lazy evaluation #71
Lazy evaluation #71
Conversation
mdellweg
force-pushed
the
lazy_evaluation
branch
3 times, most recently
from
c2b06c8
to
fcf629c
Compare
mdellweg
force-pushed
the
lazy_evaluation
branch
3 times, most recently
from
b75f7d7
to
7078d33
Compare
mdellweg
force-pushed
the
lazy_evaluation
branch
from
7078d33
to
ac97070
Compare
| return super().create(parameters=parameters, body=body) | ||
|
|
||
| @property | ||
| def HREF(self) -> str: # type: ignore |
There was a problem hiding this comment.
I'm not proud of tricking the typing system here. Maybe we need to wrap the HREF in a more generally used property we can override here.
| # Workaround for improperly rendered nested resource paths and weird HREF names | ||
| # https://github.com/pulp/pulpcore/pull/1066 | ||
| return {} | ||
| return {PulpExporterContext.HREF: self.exporter["pulp_href"]} |
There was a problem hiding this comment.
@ggainey I know, this sounds like going back and forth on how we do the trickery here. But at creation time of this Context we do not want to ask the server yet for its plugins.
mdellweg
force-pushed
the
lazy_evaluation
branch
from
89f1ca0
to
8beb9d4
Compare
mdellweg
force-pushed
the
lazy_evaluation
branch
2 times, most recently
from
ef24b72
to
d7db622
Compare
mdellweg
force-pushed
the
lazy_evaluation
branch
from
d7db622
to
4e7be3d
Compare
|
Attached issue: https://pulp.plan.io/issues/8118 |
|
I added a small section to the README to explain the requirement for the help pages. And there i think, this is ready for review @daviddavis, @ggainey, @dkliban |
Explain how to perform code linting and testing, describe the need to access help pages without server calls and improve the section for version based workarounds. [noissue]
mdellweg
force-pushed
the
lazy_evaluation
branch
from
ace4d31
to
e70eb56
Compare
|
The code here looks good to me. I'm not totally sure I totally understand the value of this feature though? Part of the reason I'm asking is that this would seem to preclude the future possiblity of populating our help text screens with information from the API. I see that you call this out in #8118. Do you have any thoughts on how we can accomplish both? |
The goal is to be able to access all commands help screens without the need to provide a pulp server. Also I think taking the docstrings from the API might be undesireable, because they describe certain API calls in a level of detail that might be unappropriate for the corresponding cli command. An example can be found in this discussion: |
|
Thank you. I agree that the API text is not always what we want to display in the CLI's help screens. I assume the direction you're proposing is that we write and maintain our own set of help text in the CLI? We had this same sort of design in Pulp 2 and there were a lot of gaps in the CLI compared to the API. When I look at say the file remote creation endpoint compared to the CLI command (which has just url and name), there are a lot of options and help text there we ought to display but aren't. I do think this is a problem we ought to solve (how to make it easier to define help text) but I'm willing to accept that it's perhaps a future one. I think this over more this weekend and perhaps @ggainey and/or @dkliban want to weigh in as well? |
|
I should add, that the code itself does not rule it out, but the policy that "a help screen must not call out to a server" does. Think |
No description provided.