reproman icon indicating copy to clipboard operation
reproman copied to clipboard

pyout: "Interference" between pyout output and interactive prompt

Open yarikoptic opened this issue 6 years ago • 3 comments
trafficstars

Observed while testing #399: If upon --refresh access to the resource requires interactive session (e.g. enter a password), then

  1. It might be not 100% clear to which resource that password prompt relates
$> reproman ls --refresh
NAME                 TYPE             ID                                          STATUS          
debian-testing-conda docker-container 64e16d0fd025                                CONNECTION ERROR
discovery            ssh              88a9e369-7780-489e-a255-5a34d1b1717b        querying…       
localshell           shell            thebest                                     available       
smaug                ssh              8b253827-9133-4a3b-9405-f7b39ef88eb7        N/A             
smaug-test           ssh              16412f12-8d99-48e7-a40e-940dc4454201        N/A             
test                 docker-container c6f0d0afcdc48a93c1000…f7e9d3d368d197027c6a0 CONNECTION ERROR
Password: 

In my case it was a single one (discovery) I guess and I could identify by seeing querying…. But what would happen if it is multiple? I wonder if there is any way we would be able somehow to disambiguate?

  1. after I "fail" to authenticate (just pressed Enter) - the entry for discovery was duplicated (since pyout does not know I guess that was more output to the terminal which it was not in control of), and followup localshell line is gone:
$> reproman ls --refresh
NAME                 TYPE             ID                                          STATUS          
debian-testing-conda docker-container 64e16d0fd025                                CONNECTION ERROR
discovery            ssh              88a9e369-7780-489e-a255-5a34d1b1717b        querying…       
discovery            ssh              88a9e369-7780-489e-a255-5a34d1b1717b        CONNECTION ERROR
smaug                ssh              8b253827-9133-4a3b-9405-f7b39ef88eb7        N/A             
smaug-test           ssh              16412f12-8d99-48e7-a40e-940dc4454201        N/A             
test                 docker-container c6f0d0afcdc48a93c1000…f7e9d3d368d197027c6a0 CONNECTION ERROR
Password: 

Is there may be some way for pyout to sense that there was additional output? e.g. to have knowledge of total # of lines in the terminal and current position, so it could see if it matches its internal "knowledge"?

If there is no way, I guess the workaround could be at least some cmdline option to ls to disable concurrent querying and proceed one at a time? Or may be there is a way to "mock" PTY so it goes through pyout somehow?

yarikoptic avatar Apr 01 '19 16:04 yarikoptic

Is there may be some way for pyout to sense that there was additional output? e.g. to have knowledge of total # of lines in the terminal and current position, so it could see if it matches its internal "knowledge"?

Not that I can think of. And in general this only-pyout-can-touch-the-stream brittleness is one of the reasons I'm so "meeh" about pyout.

If there is no way, I guess the workaround could be at least some cmdline option to ls to disable concurrent querying and proceed one at a time?

That's of course doable, though I'd guess it'd be pretty annoying for users that regularly have a password-protected resource in their inventory.

kyleam avatar Apr 01 '19 17:04 kyleam

Is it possible to (may be as an option)

  • lock/suspend all callbacks while pyout is "writing" to the screen
  • unlock/resume callbacks when pyout position cursor at the line after the end of the table then if any prompt comes in, it would come after the table. Table would get rerendered after callback returns. It wouldn't be ideal, but just an idea

yarikoptic avatar Oct 15 '19 16:10 yarikoptic

Is it possible to (may be as an option)

  • lock/suspend all callbacks while pyout is "writing" to the screen

When there are asynchronous workers, a lock is already acquired any time a write happens to the table (or actually even if the internal representation of the table is update).

  • unlock/resume callbacks when pyout position cursor at the line after the end of the table then if any prompt comes in, it would come after the table. Table would get rerendered after callback returns.

The problem is that this still messes up pyout logic for counting rows and figuring out how far it should go up (same issue mentioned in pyout/pyout#93). There might be a smarter way to do this that avoids such counting, but I haven't hit on it.

kyleam avatar Oct 30 '19 18:10 kyleam