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

Improve clarity and usability of README for first-time Howitz users #86

Merged
merged 31 commits into from
Jun 7, 2024

Conversation

podliashanyk
Copy link
Contributor

@podliashanyk podliashanyk commented Mar 22, 2024

Improvements stem mostly from the user test on @stveit where he was setting up Howitz to run for the first time by following the docs in the README.

Closes #93

Otherwise pip might complain about several directories having the same name: howitz venv dir and howitz module dir
Makes it easier to see this info and use it. Also marks this info clearly as an optional one
User testing showed that this info wasn't apparent enough for a new user
Don't assume user has read the run in dev section before reading this section
There was confusion for a first-timer about what this value should be because of "tld"
It shows how to configure alternative connections, yet doesnt require any action for new users when they copy values from the example config file to the actual config file
@podliashanyk podliashanyk self-assigned this Mar 22, 2024
@podliashanyk podliashanyk added documentation Improvements or additions to documentation beta Part of beta release usability testing Needs or is a part of UX testing labels Mar 22, 2024
@codecov-commenter
Copy link

codecov-commenter commented Mar 22, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Please upload report for BASE (main@b07d8c9). Learn more about missing BASE report.

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #86   +/-   ##
=======================================
  Coverage        ?   48.98%           
=======================================
  Files           ?       15           
  Lines           ?      835           
  Branches        ?        0           
=======================================
  Hits            ?      409           
  Misses          ?      426           
  Partials        ?        0           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link

github-actions bot commented Mar 22, 2024

Test results

  4 files    4 suites   8s ⏱️
14 tests 14 ✔️ 0 💤 0
56 runs  56 ✔️ 0 💤 0

Results for commit 5a5b366.

♻️ This comment has been updated with latest results.

@podliashanyk podliashanyk marked this pull request as ready for review March 22, 2024 10:00
Copy link
Contributor

@johannaengland johannaengland left a comment

Choose a reason for hiding this comment

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

Set up worked quite smoothly, no complaints there.

I will add some commits containing small typo/article/formulation fixes.

@podliashanyk
Copy link
Contributor Author

One nitpick (other than my inline ones): I saw several references to the configuring the backend "Zino 1" server. I don't think we should specify which version of Zino to connect to, all the while we are developing a compatible version 2 of Zino.

Created a separate issue for this #91

README.rst Outdated
The easiest way to configure Howitz is via a ``toml`` file.

1. Create an empty ``.howitz.toml`` file in the project root folder.
2. Copy the values from the example config file ``dev-howitz.toml`` to ``.howitz.toml``.
Copy link
Contributor

Choose a reason for hiding this comment

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

I haven't found a good way to mute the logging that happens on startup unfortunately. Maybe we should ship a default logging config that does that, or use a flag to explicitly turn it on.

README.rst Outdated

There's a handler "debug" that will copy everything DEBUG or higher to a file
There's a handler ``debug`` that will copy everything DEBUG or higher to a file
Copy link
Contributor

Choose a reason for hiding this comment

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

Better: "As for logging, there is a handler"..

dev-howitz.toml Outdated
Comment on lines 22 to 27
level = "ERROR"

## Comment out and tweak in order to configure logging level for dev or prod
#[logging.formatters.default]
#format = "%(levelname)s %(name)s in %(funcName)s: %(message)s"
#
Copy link
Contributor

Choose a reason for hiding this comment

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

With this, the config file is suitable neither for development nor production without major alterations. I'm not sure this is a good idea. @lunkwill42?

Copy link
Member

Choose a reason for hiding this comment

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

If we want a clean separation, the example config file referenced in the README should not be a file called dev-howitz.toml. howitz.toml.example could do - then we could keep a howitz.dev.toml.example or something. Normal folks do not want to start with the latter file, @hmpf @podliashanyk

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I like the idea with multiple example files!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added howitz.min.toml.example and howitz.dev.toml.example and updated the docs.
Is there a need to provide an additional example file for prod? Or do we just rename the dev one to howitz.toml.example? @hmpf @lunkwill42

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I took a closer look at the "Configuration"-section in the README. It describes the differences between dev config and prod config, and mentions the example file. So I landed on having a universal extended howitz.toml.example and a minimal howitz.min.toml.example.
Updated the README accordingly.

Copy link
Member

@lunkwill42 lunkwill42 left a comment

Choose a reason for hiding this comment

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

Everything looks a lot better now - but we need a decision on multiple example config files. We want to satisfy devs without confusing regular users...

dev-howitz.toml Outdated
Comment on lines 22 to 27
level = "ERROR"

## Comment out and tweak in order to configure logging level for dev or prod
#[logging.formatters.default]
#format = "%(levelname)s %(name)s in %(funcName)s: %(message)s"
#
Copy link
Member

Choose a reason for hiding this comment

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

If we want a clean separation, the example config file referenced in the README should not be a file called dev-howitz.toml. howitz.toml.example could do - then we could keep a howitz.dev.toml.example or something. Normal folks do not want to start with the latter file, @hmpf @podliashanyk


[logging]
version = 1

[logging.root]
level = "DEBUG"
level = "ERROR"
Copy link
Contributor

Choose a reason for hiding this comment

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

Let this one go back to debug since it is for developers.

Copy link
Contributor

Choose a reason for hiding this comment

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

I would add this:

[logging.formatters.default]
format = "%(levelname)s %(name)s in %(funcName)s: %(message)s"

[logging.handlers.null]
class = "logging.NullHandler"

[logging.handlers.wsgi]
class = "logging.StreamHandler"
stream = "ext://flask.logging.wsgi_errors_stream"
formatter = "default"

They are not used unless the [logging.loggers.MODULE]-stuff is also included.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This seems to clutter the minimal file. Don't really see the reason to include it especially since it will not be activated unless [logging.loggers.MODULE]-stuff is included.

@podliashanyk podliashanyk requested review from hmpf and lunkwill42 June 3, 2024 11:29

[howitz]
storage = "./howitz.sqlite3"
devmode = true
Copy link
Member

Choose a reason for hiding this comment

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

What's devmode do? Doesn't sound very production-y to me...

Copy link
Contributor Author

@podliashanyk podliashanyk Jun 6, 2024

Choose a reason for hiding this comment

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

devmode is primarily used for flask app configuration. Values for flask server address and flask storage location will have reasonable dev defaults if devmode is True and are empty otherwise. @hmpf are there any other use cases for devmode in Howitz?

Good point, it shouldn't be set to true in example config without additional changes! Will fix.

Copy link
Contributor

Choose a reason for hiding this comment

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

We tried adding a cli-flag devmode to make it very explicit when running for development: debug is set to True as well as some other things. But we stopped trying to support it as a cli-flag and now keep it only in the config-file because making it work with flask --app howitz run was proving too hard/not worth the effort.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Have added warnings in the README about checking out the "Config file for production"-section when configuring Howitz for prod.
But I have a mild suspicion that the mentioned "Config file for production"-section is somewhat incomplete. Have created #109

@podliashanyk podliashanyk requested a review from lunkwill42 June 6, 2024 13:48
Copy link
Member

@lunkwill42 lunkwill42 left a comment

Choose a reason for hiding this comment

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

Fine by me - if my assumption about refresh intervals hold true - otherwise, 5 would be a bad default 😆

README.rst Outdated
Comment on lines 249 to 251
The refresh interval for the events table can be changed by adding for example ``refresh_interval = 10`` to
the ``[howitz]``-section or setting the environment variable ``HOWITZ_REFRESH_INTERVAL`` to a new value.
Refresh interval values are in seconds and must be integers. The default value is ``5`` seconds.
Copy link
Member

Choose a reason for hiding this comment

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

Question: After the NTIE PR was merged, I hope refresh interval refers to often HTMX is set to poll the Howitz backend for NTIE updates, not to an interval of full table refreshes?

Copy link
Contributor Author

@podliashanyk podliashanyk Jun 6, 2024

Choose a reason for hiding this comment

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

Thats right, it refers to the interval for NTIE updates! NTIE PR is already merged #87 so there is no more interval (or code for that matter) for full table refreshes in Howitz anymore. 😌

Copy link
Contributor Author

@podliashanyk podliashanyk Jun 6, 2024

Choose a reason for hiding this comment

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

The naming refresh/poll is still confusing unfortunately. We decided to use word poll for "poll router or interface"-feature, and word refresh for "poll Zino server for NTIE updates"-feature.
I will add a sentence with clarification on it in the README. 🙃

@podliashanyk podliashanyk changed the title Add more user docs about running Howitz for the first time Improve clarity and usability of README for first-time Howitz users Jun 6, 2024
@podliashanyk podliashanyk requested a review from lunkwill42 June 7, 2024 08:44
@podliashanyk podliashanyk merged commit 0f25da1 into main Jun 7, 2024
5 checks passed
@podliashanyk podliashanyk deleted the improve-setup-docs branch June 7, 2024 11:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
beta Part of beta release documentation Improvements or additions to documentation usability testing Needs or is a part of UX testing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Install instructions do not work
5 participants