Bug 1289910

Summary:	RFE: Python PMAPI support for Python client -g / -p options
Product:	[Fedora] Fedora	Reporter:	Marko Myllynen <myllynen>
Component:	pcp	Assignee:	Nathan Scott <nathans>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	23	CC:	brolley, fche, lberk, mgoodwin, nathans, pcp, scox
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-09-26 06:22:59 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Marko Myllynen 2015-12-09 10:40:49 UTC

Description of problem:
-g / -p command line options are used by some clients (like pmval and pmstat) to interact with pmtime and there are few related methods in the Python PMAPI for these already but it was determined that more would be needed to allow Python clients to implement support for -g and -p. This is certainly low prio.

Comment 1 Marko Myllynen 2016-06-22 11:08:19 UTC

Thinking about this a bit more, perhaps we should do the opposite. Currently the Python PMAPI does not depend on Qt and other such libraries but if we were to complete -g/-p support there might be such dependencies even though none of the existing tools need that and the gain is marginal at best. The needed amount of work in pmgui.py is also non-trivial (just to get to the point where it could be considered from client perspective).

So perhaps it could be considered that the current methods are deprecated and turned into no-ops and leave them like that unless someone comes up very convincing use case for them (so far there hasn't been any).

Thanks.

Comment 2 Nathan Scott 2016-06-22 21:46:51 UTC

(In reply to Marko Myllynen from comment #1)
> [...]
> the Python PMAPI does not depend on Qt and other such libraries but if we
> were to complete -g/-p support there might be such dependencies even though

FWIW, libpcp_gui is all socket/protocol code wrt these options, doesn't directly add a dependency on Qt.

> So perhaps it could be considered that the current methods are deprecated
> and turned into no-ops and leave them like that unless someone comes up very
> convincing use case for them (so far there hasn't been any).

+1  although some (console) tools are definitely helped in their archive navigation by pmtime - that's really the primary use case of these options.  Oh, and making tools work together - used to be called "pmlaunch" in old school PCP (where one GUI tool could launch a console tool in a pop-up window, attached to same time controls via -p option).

cheers.

Comment 3 Nathan Scott 2016-09-26 06:22:59 UTC

Marking as very unlikely to be fixed ever, based on current resourcing levels and priorities of the people working on PCP, as well as relevant #c1 notes.  Please feel free to re-open with patches though, if this functionality is implemented & we'll happily merge it.