Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Entry point to print test logs from JSON output. #684

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

jeffherman
Copy link

@jeffherman jeffherman commented Dec 20, 2017

Test results produced by OpenHTF are in JSON format. This entry point facilitates perusing through complex logs by parsing the JSON and color-highlighting each line based on its logging level. To run:

$ openhtf-testcat your_test_output.json


This change is Reviewable

# See the License for the specific language governing permissions and
# limitations under the License.

"""Output a JSON-encoded log output to standard out.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be in contrib/ or bin/, not util/

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

setuptools.find_packages (used in setup.py) will only search for directories with __init__.py. Adding either contrib/ or bin/ to openhtf's package list will result in either contrib or bin being a top-level importable module. While it's unlikely that anyone would ever publish a bin or contrib pypi module, it's not clear that we should be co-opting this part of the namespace for openhtf-specific purposes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @jeffherman. Unless you want to force people to go to our GitHub page and download utilities separately, stuff like this should go somewhere inside the actual package.

However I am an advocate of using runnable modules (invoke with python -m) instead of declaring entry points for setuptools to wire up executable scripts. In my anecdotal experience, the entry points mechanism is more brittle and doesn't always work with all environments. Whereas if you've gotten as far as successfully making the packager itself importable, it's more unlikely runnable modules within will fail.

@jettisonjoe
Copy link
Contributor

@Kenadia, I remember having talked about this at one of the maintainers' meetings. Do you remember what our consensus was? I feel like we agreed on the runnable module approach but I can't remember where we decided to put them. Were we going to add a tools/ or bin/ to util/ or somewhere else in the package?

@Kenadia
Copy link
Contributor

Kenadia commented Apr 27, 2018

@jeffherman, I talked with @jettisonjoe, and if you'd like to update this PR, we'd like to put this script in a openhtf/util/bin/ directory. Users can then run the script with python -m openhtf.util.bin.testcat (as opposed to the setuptools method)

(As an aside, I wonder if the name print_logs.py would be more accurate than testcat.py.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants