Install Only What the Course Requires

Install the smallest environment that satisfies the course’s documented requirements. Match required versions, keep project dependencies isolated when the ecosystem supports it, retain dependency records, and document how you verified the installation.

More tools do not create a more capable beginner environment. They create more possible sources of version and path conflicts.

Start with course evidence

Before downloading anything, collect:

• the syllabus and current assignment instructions;
• an instructor-provided setup guide;
• the starter project’s README and configuration files;
• required language and tool versions;
• supported operating systems;
• required editor or IDE, if any;
• dependency installation commands; and
• the exact command used to run or test the first exercise.

Treat a classmate’s setup, an old video, and an AI-generated list as leads, not authority. They may describe another semester or operating system.

Create three lists:

Do not install the not now list.

Separate base tools from project dependencies

Base tools may serve several projects:

• a course-approved editor;
• the required language implementation or development kit;
• Git, when the course uses it; and
• a package or environment manager required by the workflow.

Project dependencies belong to one project or a controlled environment:

• libraries;
• test frameworks;
• linters and formatters;
• project scripts; and
• exact transitive packages selected by a lock file.

The boundary varies by ecosystem. Follow the course’s tool, directory, and version rules rather than inventing a universal folder layout.

Use isolated environments when instructed

An isolated environment lets projects use different dependency sets without placing every package into one shared installation.

Python’s official documentation explains that a virtual environment contains a particular Python installation and packages for an application, allowing projects with conflicting package versions to remain separate. See Virtual Environments and Packages.

Other ecosystems use different mechanisms. Some create a project-local dependency directory. Some select tool versions through a project file or environment manager. Use the method already chosen by the course.

An environment does not fix an incorrect base language version. Record both the base version used to create it and the dependencies installed inside it.

Dependency files describe intent and resolved state

A project may contain:

• a manifest that names direct dependencies and version constraints;
• a lock file that records a resolved dependency graph;
• a requirements file;
• a build configuration; or
• a course-provided installation script.

These files are part of the project. Do not recreate the dependency list from memory or install “the latest” version of every package.

Lock-file behavior is ecosystem-specific. npm, for example, documents package-lock.json as an automatically generated record for operations that modify the dependency tree or package.json. See the official package-lock.json documentation. Do not generalize npm’s rules to Python, Java, or another tool.

Keep course-provided manifests and lock files unless the instructions say otherwise. Do not edit a lock file by hand merely to make an error disappear.

Avoid unnecessary global installation

Global installation can make a tool available broadly, but it can also:

• hide a missing project dependency;
• select the wrong version;
• require elevated privileges;
• affect unrelated projects; or
• make your environment difficult to reproduce.

Use global installation only when the official course or ecosystem workflow assigns the tool a global role. Prefer a normal user account and the least privilege required.

Never use administrator access to force a failed package installation before you understand the error and the expected target environment.

Follow the correct platform module

Installation commands differ across Windows, macOS, and Linux. Shell syntax, paths, package sources, and required permissions also differ.

Use the platform module that matches:

• your operating system;
• your shell;
• the current course version; and
• whether the computer is personally or institutionally managed.

Do not combine half of a Windows guide with half of a macOS guide. On a managed device, use the institution’s software channel or request process.

Document the installation

Keep a short environment record:

# CS 101 programming environment

- Course setup guide and date checked:
- Operating system:
- Shell:
- Editor or IDE:
- Language implementation and version:
- Package or environment manager and version:
- Project dependency file:
- Environment location:
- Install command used:
- Verification command:
- Test project and expected result:
- Not installed and why:

Record commands without secrets. If an installer changes the command search path or requires a new terminal session, record that observation.

Verify the complete path

Version output is necessary but incomplete. Verify:

1. the command resolves in a new normal-user terminal;
2. the reported version matches the course;
3. the course starter project opens from its root;
4. dependencies install through the documented project method;
5. the smallest provided program runs; and
6. the provided test command reports the expected result.

A successful editor launch does not prove that its integrated terminal uses the same runtime or environment.

Common mistakes

• Installing every tool mentioned in a tutorial series.
• Selecting the newest version instead of the required version.
• Mixing system, user, and project package installations.
• Deleting or regenerating a course lock file without authorization.
• Using administrator access to bypass an unexplained error.
• Installing an editor extension but not the required runtime.
• Failing to document the source and version of an installer.
• Testing only in an already configured terminal.

Do this now

Start with one required tool from one current course. Confirm the official requirement and verify that tool before expanding the installation inventory.

Create the three installation lists. For each required item, cite the course source that requires it and record one verification command. Move anything without current evidence to not now.

If installation is already complete, audit it instead of reinstalling. Compare the observed versions and project files with current course instructions.

Log what you learned

Record only:

• Result: What did the action produce?
• Evidence: What observation, test, or source supports that result?
• Next action or unresolved question: What should happen next?