Hi Jason, Cool work! A few thoughts: 1. This seems to have copied the condor_chirp behavior of having no timeouts and/or hanging indefinitely on remote error. Probably worth changing... might I suggest 20 second timeouts? 2. There's actually a few chirp commands that can be done without setting IO proxy -- sending delayed updates comes to mind. 3. Can we add documentation to http://htcondor-python.readthedocs.io? 4. You probably want the object to behave as a context manager to avoid tons of connects / disconnects: import htchirp with htchip.HTChirp() as chirp: chirp.ulog("I'm using HTChirp!") chirpt.set_job_attr("UsingHTChirp", "True") It'd be straightforward to avoid this disconnects, and it'll also make the code exception safe. For example, it's possible to have a dangling connection here: 5. Do we need to worry about sending the server responses greater than 1024 bytes? I seem to recall that the starter code in that area seemed a bit ... crashy ... with large responses. Even if it doesn't cause a crash, it might be worthwhile to have a reasonably good error message if too-long filenames can cause protocol violations. 6. What Unicode encoding issues should we think about? That's always been a bit mysterious to me in HTCondor land -- and potentially problematic as Python 3 marches forward. 7. Would love to see some appveyor / Travis-CI style integration tests! Hope this is helpful, Brian
|