Chapter 2: Getting started with Streamlit

Introduction

This chapter introduces the path from preparing a Streamlit development environment through learning the development workflow to building a first password-checker app.

• Chapter learning sequence: Describe the chapter's sequence: first set up a development environment, then examine the Streamlit development workflow, and finally build and run a first app.
  Why it matters: This sequence frames the practical foundation used to build Streamlit apps throughout the book.
• Development environment considerations: State that the chapter treats Git version control, code editing tools, and virtual environments as three key considerations when setting up a productive Streamlit development environment.
  Why it matters: These setup choices help a developer stay productive and be better positioned to create real-world Streamlit apps.
• Chapter code repository: State that the book's GitHub repository is github.com/aneevdavis/streamlit-in-action and that the chapter_02 folder contains this chapter's code.
  Why it matters: Knowing where the chapter code lives lets readers find the accompanying examples while working through the exercises.

Key terms: development environment, Streamlit development workflow, password checker, version control, Git, code editing tools, virtual environments, GitHub repo, streamlit-in-action, chapter_02

2.1 Getting Streamlit up and running

This section identifies the Python and pip prerequisites and the pip command needed to install Streamlit.

• Streamlit installation prerequisites: State that Streamlit requires a supported Python installation and pip, and identify the supported and recommended Python versions.
  Why it matters: These prerequisites let you install Streamlit before creating or running an app.
• Pip installation command: Describe using pip to install Streamlit by running the command "pip install streamlit".
  Why it matters: This command installs the Streamlit package so the development workflow can begin.
• Appendix installation guide: State that the appendix contains the detailed installation guide for Streamlit setup.
  Why it matters: The appendix is the section's reference when more step-by-step installation help is needed.

Key terms: Python, Python 3.9, Python 3.11+, pip, pip install streamlit, Streamlit, appendix, installation guide

2.2 Setting up your development environment

This section introduces the development-environment choices that affect Streamlit development productivity and previews version control, code editors, and virtual environments.

• Development environment choices: Explain that development tools and environment setup are largely personal preferences, but can significantly affect a developer's productivity over time.
  Why it matters: Choosing a setup deliberately can make building and maintaining apps more productive.
• Environment setup topics: State that the upcoming development-environment topics are version control, an editing tool, and virtual environments.
  Why it matters: These are the three setup areas the following subsections address before you start running Streamlit.
• Experienced developer guidance: Describe the guidance for experienced Python developers: if they already have a development setup they are comfortable with, they can skip ahead to running Streamlit for the first time.
  Why it matters: The book distinguishes between readers who need setup guidance and those ready to begin using Streamlit.

Key terms: development environment, productivity, version control, editing tool, virtual environments, experienced Python developer, running Streamlit for the first time

2.2.1 Version control with Git

This subsection explains Git as version control for tracking, revisiting, experimenting with, and documenting code changes during development.

• Git as version control: Explain what version control is and how the book uses Git as its name for version control. Describe Git as a structured way to track and manage changes to programs, like a time machine for code.
  Why it matters: Git gives you a reliable history of your code rather than forcing you to treat each change as permanent.
• Code history and experimentation: Describe how Git supports returning to an earlier version of code, applying changes from that point, and trying multiple design options while switching between versions.
  Why it matters: Being able to revisit and compare versions makes it safer to change direction while building an app.
• Change documentation benefits: Explain that Git provides a place to document code changes and the reasoning behind decisions, which is especially useful later on, on large projects, and in collaboration.
  Why it matters: A recorded explanation of changes helps you and collaborators understand decisions long after they were made.

Key terms: version control, Git, versions of your code, document changes, thought process, development workflow

2.2.2 Code editors

This section explains why a dedicated code editor or IDE improves Python and Streamlit development, compares PyCharm with VS Code, and emphasizes that any editor plus a terminal is sufficient.

• Code editor productivity benefits: Explain why a dedicated code editor or IDE is recommended over a basic text editor for writing Streamlit apps. Mention that Streamlit apps are plain Python text files but advanced tools add features such as syntax highlighting, debugging, and code navigation.
  Why it matters: Choosing an appropriate editor makes writing, finding, and fixing code substantially easier.
• PyCharm Community Edition: Describe PyCharm as a Python-focused IDE with code completion, error detection, and quick-fix suggestions. Explain that it is a strong choice for someone wanting extensive functionality immediately, and distinguish its paid Pro edition from the free Community Edition.
  Why it matters: PyCharm offers a ready-to-use Python development environment without much initial configuration.
• VS Code plugin ecosystem: Describe VS Code as a free, multi-language code editor that provides basics such as syntax highlighting but gains most of its power through plugins. Explain the trade-off that, with suitable plugins, it can approach paid PyCharm functionality, but the learner must spend time setting it up.
  Why it matters: VS Code is a flexible free option when you are willing to configure extensions for the capabilities you need.
• Tool-independent development setup: State the minimum practical setup assumed by the book: a program for editing text files and a terminal for entering commands. Explain that the book does not require a particular editor, and that regular non-AI IDEs are recommended while learning despite the availability of AI-first tools.
  Why it matters: You can follow the book with the tools you have rather than being blocked by a specific editor choice.

Key terms: code editor, Integrated Development Environment (IDE), syntax highlighting, debugging, code navigation, PyCharm, JetBrains, code completion, error detection, quick-fix suggestions

2.2.3 Virtual environments

This section explains how per-project Python virtual environments isolate dependencies to prevent library-version conflicts between projects.

• Project dependency isolation: Explain that a virtual environment is an isolated instance of Python together with the libraries and dependencies a project needs. Describe how giving each project its own environment lets its dependencies change independently of other projects.
  Why it matters: Dependency isolation helps keep changes in one Python project from unexpectedly breaking another.
• Dependency version conflicts: Describe why shared Python libraries can cause problems across real-world projects: libraries change over time, and updating one for one project can break another project or create unpredictable bugs and conflicts.
  Why it matters: Understanding version conflicts explains why isolated environments are worth using before problems arise.
• Virtual environment tool landscape: State that multiple tools support virtual-environment-related workflows, including venv, pipenv, pyenv, and poetry, and that they offer varying levels of sophistication.
  Why it matters: Recognizing these tool names helps you identify common options when choosing an environment workflow.

Key terms: virtual environment, isolated instance of Python, libraries, dependencies, versions, dependency management, bugs, conflicts, venv, pipenv

2.3 Running Streamlit for the first time

This section runs Streamlit’s built-in Hello app so readers can see example capabilities and inspect their concise source code.

• Hello app launch: Describe how to start Streamlit’s included Hello app by opening a terminal and running `streamlit hello`, and state what happens next in the terminal and browser.
  Why it matters: Running the Hello app verifies that Streamlit is installed and gives you a working first app to explore.
• Hello app capabilities: Describe the kinds of Streamlit capabilities demonstrated by the Hello app, including animation, graph plotting, maps, tables, and a pandas-dataframe example navigated through the sidebar.
  Why it matters: The demos provide a concrete first impression of the interactive and data-oriented apps Streamlit can create.
• Source code inspection: Explain that the Hello app’s sidebar has a Show Code checkbox that reveals an app’s source code below the app, illustrating that Streamlit code need not be verbose.
  Why it matters: Seeing the code beside a working demo helps connect Streamlit’s polished results with relatively concise Python code.

Key terms: Hello app, streamlit hello, terminal, animation, graph plotting, maps, tables, pandas dataframes, sidebar, Show Code

2.4 The Streamlit development workflow

This section presents the iterative Streamlit workflow for writing, running, testing, revising, and rerunning an app.

• Iterative development workflow: Describe the Streamlit development workflow as a repeating cycle: write and save Python code, run the app, test it in the browser, revise the code, save again, and repeat.
  Why it matters: This cycle is how you progressively turn an app idea into working Streamlit software.
• App launch command: State that a saved Python app is launched from a terminal with streamlit run <filename>, replacing <filename> with the path to the Python file, which opens the app in a browser.
  Why it matters: You need this command to start a Streamlit server and view the app you are developing.
• Saved-change reruns: Explain that after changing and saving Python code, you normally do not run streamlit run <filename> again; instead, return to the browser and either enable Always Rerun for automatic reruns or click Rerun manually.
  Why it matters: Using reruns lets you see edits quickly without repeatedly restarting the app server.
• Server restart exceptions: Describe the exception that changes outside the Python code, such as changes to a dependent text file or database, may occasionally require shutting down and restarting the Streamlit app before they take effect.
  Why it matters: This helps you recognize when an ordinary rerun is insufficient to pick up a change.

Key terms: Streamlit development workflow, Python file, code editor, terminal, browser, streamlit run <filename>, .py extension, browser window, Always Rerun, Rerun

2.5 Building your first app

This introduction previews the first-app walkthrough and encourages active experimentation while following it.

• First-app walkthrough roadmap: Describe the sequence the first-app material will follow: introduce the app concept and logic flow, explain the complete code, then run and modify the app.
  Why it matters: Knowing the roadmap helps you connect the app’s idea, code, execution, and changes as one learning process.
• Active experimentation mindset: Explain why the section recommends tinkering and making changes beyond the prescribed steps while learning the app.
  Why it matters: Active exploration can make the material more memorable by helping you discover how it works for yourself.

Key terms: concept, logic flow, complete app code, tinkering, experimenting, active role, initiative

2.5.1 A password checker

Introduces a password-checker app in which a user enters a password and receives pass/fail feedback for each password rule.

• Password checker purpose: Describe the password checker as an app where a user enters a password and sees which password rules pass and which fail.
  Why it matters: This defines the user-facing behavior that the first Streamlit app will implement.

Key terms: password checker, password rules, pass, fail

2.5.2 Logic flow

This section traces how the password checker turns a user-entered password into rule results and color-coded feedback on screen.

• Password checker logic flow: Trace the password checker’s flow from password entry and button click through checking stored rules, creating results, and displaying the outcomes.
  Why it matters: This flow connects the app’s user interaction, internal checking logic, and visible feedback.
• Color-coded rule feedback: Describe how each checked password condition is presented as a separate result box, using green for PASSED conditions and red for FAILED conditions.
  Why it matters: Color-coded per-rule feedback lets a user see which password conditions are satisfied and which are not.

Key terms: text input box, button, rules, dictionary, PASSED, FAILED, results, green, red, condition

2.5.3 Going through the code

This section walks through the password checker code, connecting its Python validation logic to the Streamlit elements that collect input and display rule-by-rule feedback.

• Password rule definitions: Describe how the app represents password requirements in a Python dictionary whose rule names map to lambda functions. Explain that each lambda receives the password and returns True or False, including the length, uppercase-letter, and lowercase-letter checks.
  Why it matters: This pattern separates the validation rules from the code that evaluates and presents them.
• Password property evaluation: Explain how get_password_properties evaluates every rule and returns a new dictionary that maps each condition to its Boolean result. Describe this as a dictionary comprehension that applies each rule function to the entered password.
  Why it matters: The returned condition-to-result mapping lets the app give feedback for every password requirement.
• Streamlit input and feedback flow: Trace the user-facing Streamlit flow: st.title displays a heading, st.text_input collects and stores a password, and st.button gates the validation code. Explain that after a click, a non-empty password is evaluated and each result is shown with st.success or st.error, while an empty input produces an st.write prompt.
  Why it matters: This is the basic pattern for turning Python logic into an interactive Streamlit interface with clear user feedback.
• Streamlit import convention: State that Streamlit is imported for the app and conventionally given the alias st, which is why its elements are called as st.<element name>.
  Why it matters: Recognizing the st prefix makes it easier to read and write Streamlit code.

Key terms: dictionary, keys, values, lambda, anonymous inline functions, pw, get_password_properties, dictionary comprehension, conditions, results

2.5.4 Running the app

This section shows how to launch the Password Checker app locally, access it through Streamlit’s URLs, and troubleshoot browser-launch problems.

• Local app launch: Describe how to run the saved Password Checker Python file from a terminal using the Streamlit run command, and state what happens after it starts. Include that Streamlit prints terminal output and normally opens the app in a browser.
  Why it matters: Running the app locally lets you test it and observe changes while you develop.
• Local and network URLs: Explain what the Local URL in Streamlit’s terminal output means: the app is served by a Streamlit server on the reader’s computer, usually at localhost on port 8501, though the port can differ. Describe how the displayed Network URL may let other computers on the network reach the app, subject to network and firewall configuration.
  Why it matters: Knowing which URL to use helps you open a local app manually and understand who may be able to reach it.
• Browser access troubleshooting: Describe the first troubleshooting steps when Streamlit does not open a browser automatically or the browser page is blank: manually enter the displayed Local URL, try an up-to-date browser, and try a different browser such as Chrome. State that the terminal should remain open while the app is running.
  Why it matters: These checks help you reach a locally running app when automatic browser access fails.

Key terms: streamlit run, terminal, Password Checker, Streamlit server, Local URL, Network URL, localhost, port 8501, localhost:8501, browser

2.5.5 Making changes to the app

This section shows how to modify the Password Checker app and have Streamlit rerun it to display saved code changes.

• Password checker updates: Describe the two edits made to the Password Checker app: add a condition requiring at least one numeral and change the button text to include an exclamation point. Explain that rerunning the updated app shows both the new numeral test and the changed button label.
  Why it matters: Making a small visible and functional change confirms that edits to the Python source become changes in the app.
• Source-change rerun controls: Explain that Streamlit monitors the app source file after it is saved and notifies the browser when it changes. Distinguish Rerun, which runs the latest code on demand, from Always Rerun, which automatically updates the app after code changes, and describe how to turn that automatic behavior off through Settings by unchecking Run on Save.
  Why it matters: Understanding these controls lets you quickly see edits in the browser while retaining control when automatic updates make changes hard to notice.

Key terms: conditions dictionary, numeral test, Check Password!, source file, Rerun, Always Rerun, Run on Save, Settings

2.5.6 Killing and restarting the server

This section explains how to stop a running Streamlit server and restart it so browser app instances can reconnect.

• Server shutdown and resource use: Describe how to shut down a running Streamlit server by closing its terminal window or pressing Ctrl-C, and explain why you might do this when finished using the app.
  Why it matters: Stopping an unused server prevents it from continuing to consume resources.
• Browser behavior after shutdown: Explain what happens in an open browser app when its Streamlit server is shut down: the app can no longer be interacted with, its button is disabled, and it shows CONNECTING and a connection error.
  Why it matters: These browser signals help you recognize that the frontend has lost its connection to the server.
• Server restart and reconnection: Describe restarting the app by running streamlit run <filename> again, including that this starts a new server, opens a new browser window with a different app instance, and lets the old browser window reconnect too.
  Why it matters: Restarting restores the connection between the frontend and a running Streamlit server so the app becomes usable again.

Key terms: Streamlit server, terminal window, Ctrl-C, frontend app, CONNECTING, connection error, disabled button, streamlit run <filename>, restarts your server, frontend

2.6 Summary

This summary recaps the Python requirement, essential development tools, and the command-and-rerun workflow for running Streamlit apps.