Execution Environment Setup

This page gives you the practical knowledge to make informed, team-level decisions about your project’s execution environment — the foundation that lets everyone run, build, and share the software consistently.
Think of it like setting up a shared kitchen: before cooking together, you must agree on the tools, ingredients, and cleaning rules.

Glossary

Runtime / Interpreter / Compiler – The program that actually runs or translates your code (e.g., Python, Java, Node).
LTS (Long-Term Support) – A version that receives updates for years, preferred for stability.
SDK / JDK – Software Development Kit / Java Development Kit: bundles tools for building and running programs.
Package Manager – A tool that installs and updates third-party libraries (e.g., pip, npm, Gradle).
Dependency – External library or framework your code relies on.
Lockfile – A generated file that freezes dependency versions for reproducible installs.
Virtual Environment – An isolated workspace so one project’s libraries don’t conflict with another’s.
Build / Distribution – The process of packaging code so others can install or run it.
CI/CD – Continuous Integration / Continuous Delivery: automated build and test pipelines.

Choosing the Runtime

Every programming language evolves. Choosing the right runtime version is like choosing the right kind of fuel for your car — too old, and you miss safety fixes; too new, and the engine might not fit.
Pick a version that is stable, supported, and compatible with the libraries you plan to use.

Tip

Use LTS versions unless you have a strong reason not to.
They are tested longer, documented better, and less likely to break your builds mid-semester.

Danger

Mixing runtime versions inside one team leads to “it works on my machine” chaos.
Decide together, write it down, and make sure everyone uses the same setup.

Package Managers and Reproducibility

A package manager automates installing libraries — like an app store for code. But unlike a phone app store, every project may need a different version of the same library.
Reproducibility means that anyone who clones the project and runs install should end up with the exact same versions.

Good practice: - Commit lockfiles into version control. - Separate production and development dependencies. - Document install commands for each operating system.

Example

Python: poetry.lock or requirements.txt
Node: package-lock.json
Java: Gradle or Maven wrapper

Info

Never edit lockfiles by hand — they are machine-generated records of your dependency state.

Managing Virtual Environments

Virtual or SDK environments isolate your project’s dependencies from the rest of your system.
It’s like using a sandbox to build your castle: everything stays contained, so others can build the same one.

Each team should use project-local environments. They make it easier to help each other, since the setup is predictable.

Tip

Always document how to create and activate your environment.
Include example commands for Windows, macOS, and Linux.

Danger

Never commit your .venv, node_modules, or .gradle folders.
These can weigh hundreds of megabytes and make the repository unmanageable.

Selecting Dependencies Wisely

Dependencies save time — you don’t reinvent the wheel. But too many, or the wrong ones, can slow you down or even break your project later.

When evaluating a library, check: - Maintenance – Is it updated regularly? - License – Is it legal to use in your project? - Popularity – Does it have community support? - Compatibility – Does it fit your chosen runtime and other tools? - Performance – Is it light enough for your use case?

Example

Python: rich (better console output), pytest (testing), tqdm (progress bars)
Java: JUnit (testing), Jackson (JSON processing)

Tip

Write down why you chose each dependency — future teammates (and you) will thank you when something needs replacing.

Danger

Large or abandoned libraries can slow builds, increase security risks, and make updates painful.

Distributing and Building Your Software

Once your code works, others need to run it. Distribution is how you turn a project folder into something usable — a packaged release, container, or simple zip.

Think about: - Who will run your program — classmates, tutors, users? - How they will get it — pip install, .jar file, web URL, or container? - How they will know it works — quick start instructions, version tags, and a smoke test.

Info

Use semantic versioning (1.2.3) or date-based (2025.04.0) tags.
This helps track what changed and when.

Example

“Build → Tag → Test → Release” should be repeatable with documented commands.
No manual file copying.

Danger

Don’t rely on local hacks or “it works on my laptop” builds.
Your project must be reproducible from source by any teammate.

Putting It All Together

The execution environment is the invisible backbone of your project. It affects: - Whether your teammates can run each other’s code.
- How easily you can test, debug, and deliver.
- Whether your project survives this semester.

Take time to set it up carefully. Ask “why” for every tool and version you choose.
Document clearly so any new teammate could get the system running in one try.

Quote

“If your code can’t run on a clean machine, it doesn’t really exist.”