Day 1- Python Environment Setup, Industry Project Configuration And Package Management

Python “industry readiness” starts long before writing code: it hinges on getting the environment right, keeping dependencies isolated, and packaging projects so they can be installed and shared cleanly. Day 1 lays out a practical setup path—installing Anaconda, configuring command-line access, setting up Visual Studio Code, creating virtual environments, and managing packages—then moves into how Python projects become reusable packages via setup.py and pyproject.toml. The payoff is fewer “works on my machine” failures and a workflow that scales from experiments to real ML/GenAI projects.

The session begins with an installation walkthrough focused on Anaconda on Windows, where the most common failure is forgetting to add Anaconda to the PATH. During installation, a checkbox labeled to add Anaconda to the environment variable is treated as non-optional; without it, the conda command won’t be recognized in the terminal. For people who already installed without that checkbox, the fix is to manually edit system/user environment variables and add the expected Anaconda paths (scripts, Library/bin, Library/user/bin, and the Anaconda root folder). After that, conda is tested from Command Prompt to confirm the setup is functional.

Next comes the tooling layer. Visual Studio Code is installed separately, and the workflow emphasizes using VS Code as the coding environment rather than starting in Jupyter or Google Colab. Once VS Code is running, the Microsoft “Python” extension is installed because it provides the kernel integration and core developer features like IntelliSense, debugging, formatting, and linting support. Anaconda Navigator is also introduced as a management interface for environments and installed packages, letting users select among multiple virtual environments for different projects.

The core concept—virtual environments—is then framed through a realistic scenario: one company may run multiple projects requiring different Python versions and different libraries (e.g., data science stacks, NLP libraries, agentic AI frameworks). Installing everything into a single environment leads to dependency clutter and conflicts. The recommended practice is one environment per project (or per dependency set), created with conda create -p <env_name> python=<version>. The session explains the meaning of -p (create the environment in the current working directory) and -n (create it under the Anaconda installation’s environment directory). After creation, conda activate <env_path> is required so that subsequent package installs land in the correct environment.

Package management follows. Dependencies can be installed directly with pip install, but the industry-standard approach is to list them in requirements.txt and install them with pip install -r requirements.txt. The session also covers Jupyter integration: creating .ipynb files inside the virtual environment is discouraged; instead, notebooks live in the project workspace, and the environment’s kernel must be available via ipykernel. The session recommends installing ipykernel manually rather than bundling it into production dependency lists.

Finally, the session transitions into project packaging. It introduces setup.py as a way to convert a project into an installable package, using setup tools find_packages and a get_requirements() helper that reads requirements.txt. It demonstrates the need for package structure via an __init__.py file so folders like src become importable packages. It then contrasts this with pyproject.toml, a modern configuration file used by packaging tools, showing how pip install -e . can trigger pyproject.toml-driven builds and create the same kind of package metadata more efficiently. The day ends with a preview that later sessions will focus on environment files and deeper project structure, including object-oriented programming and end-to-end ML project design.