2025-02-11 Week 5 - Session 1 - TDS Jan 25#

Duration: 3h 57m

Here’s the FAQ for the TDS live tutorial:

Q1: Will the deadline for GA5 be extended?

A1: Yes, we are currently discussing moving the GA5 deadline. We don’t have an exact date yet, but it definitely won’t be this upcoming weekend. This extension is to give you extra time to focus on Project 1 and also because we won’t be able to cover all of Week 5’s content this week.

Q2: What will be the focus of today’s and upcoming sessions this week?

A2: All three sessions this week – today, tomorrow, and the day after – will be exclusively focused on Project 1.

Q3: What will be the main goal of today’s session regarding Project 1?

A3: Today, our goal is to guide you through the basic steps needed to successfully initiate your project. We’ve received many requests for help with the fundamentals, so we’ll cover getting GitHub set up, pushing code, and ensuring you can at least run “Task A1” of your project. Running Task A1 is critical; if you can’t get that to work, you won’t be able to proceed with the rest of the project. We’ll also provide a code skeleton to help you work on other tasks.

Q4: Will the entire Project 1 be covered today?

A4: While we’re not 100% certain we’ll cover everything today, our primary aim is to get you successfully through Task A1.

Q5: Will you cover the project’s evaluation and submission steps?

A5: Yes, discussing the starting and ending steps, including how evaluation works, is on our agenda for today.

Q6: Will this session be recorded and available on YouTube?

A6: Yes, the session is being recorded and will be available on YouTube. However, remember that watching the recording means you won’t be able to ask live questions.

Q7: I’ve generated my data folder, but how can I verify if I’m defining the tasks correctly using the ’evaluate.py’ file?

A7: We will cover how to verify your tasks today. Please note that I’m currently running a virtual machine (VM) for this demonstration, and I haven’t fully verified its functionality yet, so there might be minor issues.

Q8: What are the absolute requirements for Project 1 submission?

A8: There are a few absolute requirements. You must create a GitHub repository, add an MIT license to it, and ensure your repository is set to ‘public’ before submission. If these prerequisites are not met, your project won’t even be eligible for evaluation.

Q9: Is it okay to initially set my repository to private and then change it to public later?

A9: Yes, that’s perfectly fine! I’m demonstrating with a private repository today because it’s a bit more involved, but the crucial step is to remember to make it public before submission. I’ll show you how to change it back to public later.

Q10: What is the purpose of the MIT license for Project 1?

A10: Different licenses specify what others can and cannot do with your code. The MIT license is a common public license, often used in educational contexts. For Project 1, using the MIT license is a mandatory requirement.

Q11: How do I add an MIT license to my GitHub repository if I forgot to do it during creation?

A11: You can add an MIT license to an existing repository. Navigate to your repository, click “Add file,” then “Create new file.” Name the file LICENSE (all caps), and GitHub will automatically prompt you to “Choose a license template.” Select “MIT” and then “Review and submit.” This will add the license file to your repository.

Q12: Why do we need to use WSL (Windows Subsystem for Linux)?

A12: WSL offers a separate Linux environment that protects your main system from potential issues during development. Most of the packages and commands we use for this project run optimally and are well-tested on Linux. While you can do it on Windows, WSL simplifies the process and avoids potential compatibility issues.

Q13: How do I set up WSL and Visual Studio Code (VS Code) for the project?

A13:

Install WSL: Open PowerShell and run wsl --install. After installation, restart your system.
Verify WSL: After restarting, run wsl -l -v in PowerShell to check installed distributions.
Install Ubuntu (Recommended): Use wsl --install Ubuntu-22.04 (or 24.04, which is LTS – long-term support) for a stable version. This also requires a system restart after installation.
VS Code Integration: Ensure VS Code is installed. Inside VS Code, go to Extensions and install the “WSL” extension (by Microsoft).
Launch VS Code in WSL: From your WSL terminal, navigate to your project directory and type code . This will open VS Code connected to your WSL environment, indicated by “WSL: Ubuntu-22.04” (or 24.04) in the bottom-left corner. This setup ensures your commands run within the Linux environment.

Q14: How do I configure Git within my WSL environment?

A14: Once VS Code is running within WSL and you’re in your project directory:

Initialize Git: Run git init to initialize a local Git repository.
Configure User: Set your Git username and email using:
- git config --global user.name "Your Name"
- git config --global user.email "[email protected]" These steps are crucial for identifying who makes commits.
Add Remote Repository: Link your local repository to your GitHub repository using:
- git remote add <repo_name> <repository_URL> You can get the repository URL by clicking the “Code” button on your GitHub repository page and copying the HTTPS link.
- Note: If you’re pushing from the command line, you’ll need a Personal Access Token (PAT) for private repositories, as GitHub no longer accepts passwords for Git operations over HTTPS. You can generate a PAT in your GitHub settings under “Developer settings” > “Personal access tokens.” However, using VS Code with the WSL extension simplifies this by handling authentication through your browser.

Q15: How do I push code to GitHub after making changes?

A15: Using VS Code’s integrated source control (the third icon on the left sidebar):

Stage Changes: You’ll see your modified files listed. Click the ‘+’ icon next to each file to stage them.
Commit Changes: Type a descriptive commit message (e.g., “Created app.py”) in the message box.
Push Changes: Click the “…” (more actions) menu and select “Push” to upload your changes to GitHub. VS Code will handle the authentication via your browser.

Q16: What is the purpose of UV?

A16: UV is a complete package manager that simplifies running your Python files. It can manage dependencies, create virtual environments, and launch your server. It’s particularly useful because the tasks for Project 1 will generate unique code or require various packages. UV ensures these tasks can run without conflicts or corrupting your system, as it disposes of the virtual environment once the task is complete. This makes it a safe and efficient way to execute code, especially machine-generated code.

Q17: Will UV be installed by default in WSL or do I need to install it manually?

A17: You will need to install UV manually. Once you have Python 3 installed in your WSL environment, you can install UV using pip install uv. I had to install Python 3 on my demonstration VM, and then UV, to get it running.

Q18: What is the primary purpose of the two main functions, script_runner and task_runner, in the provided Project 1 code structure?

A18: The script_runner function is designed to handle the initial task of your project. It will install necessary packages and run a Python script from a specified URL, using provided arguments. This is particularly important for Task A1, which generates essential data and files. The task_runner function will then manage other tasks (like B1, B2, etc.) that will be running throughout the project lifecycle.

Q19: How will the script_runner function get the necessary files and arguments to generate data for Task A1?

A19: The script_runner function will parametrically extract the URL of the data generation file and any required arguments from the incoming task request. This means you won’t hardcode file paths or arguments directly in your function. The script_runner will then use UV to run this script, which will generate all the necessary files (like .md, .txt, .json, etc.) that are needed for subsequent tasks.

Q20: Can I hardcode the data generation file directly into my code instead of fetching it via URL?

A20: No, you cannot hardcode the data generation file. The evaluation process will use a different version of this file, so hardcoding it will cause your project to fail. You must parametrically fetch the URL of the data generation script as part of the task execution.

Q21: How do I trigger a post request for a task, since browsers typically send get requests?

A21: You cannot send a post request directly from your browser’s URL bar. You’ll need to use an API client like Thunder Client (a VS Code extension) or Postman. Alternatively, you can write a short Python program to send a post request with the necessary headers and data.

Q22: Can you demonstrate how to set up and use Thunder Client (or Postman) to send a post request to my server for running tasks?

A22: I will demonstrate this now.

Set up Thunder Client: In VS Code, open the Thunder Client extension.
Define Request: Set the request method to POST.
URL: Use the URL http://127.0.0.1:5000/run/ (or whatever port you’ve mapped your Docker container to).
Headers: Add a Content-Type header with the value application/json. You’ll also need an Authorization header with a token, which you’ll need to generate from your Docker Hub account and fetch from your environment variables in Python.
Body: In the JSON body, provide the script_url (the URL for the data generation script), the email (your user email), and a task object containing arguments (like the script_url and user_email) and the response_url.
Send Request: Once set up, send the request. The server should process it, and you can then check the logs for its execution.

Q23: How do I push my Docker image to Docker Hub for submission?

A23:

Login: First, ensure you’re logged in to Docker Hub via your terminal using podman login docker.io.
Push Image: Use the command podman push docker.io/<your_docker_hub_username>/<your_image_name>:<tag>. For example: podman push docker.io/jivaraj18/tds_tuesday:v1. This will upload your image to your Docker Hub repository.

Q24: After pushing the Docker image, can I then pull it back down to any machine?

A24: Yes! Once your image is on Docker Hub, you can use the podman pull command with the full image name (e.g., podman pull docker.io/jivaraj18/tds_tuesday:v1) to download it to any machine. This ensures your project is portable.

Q25: I have a running Docker container. How can I ensure it keeps running and doesn’t stop, and how can I restart it if it does stop?

Q25:

Run Detached: To keep a container running in the background, use the -d (detached) flag when running the podman run command. For example: podman run -d -p 5000:8000 tds_tuesday:v1.
Check Running Containers: Use podman ps to see active containers.
Restart Stopped Container: If a container has stopped, you can restart it using podman start <container_id>. Use podman ps -a to list all containers (active and stopped) to find the ID.

Q26: What is the process for submitting Project 1?

Q26:

Fill Google Form: Access the Google Form linked on the project page under “Deliverables” > “Submit in this Google Form.”
Provide Repository Details: In the form, you must provide your GitHub repository name and your Docker image name. These should be in the format username/repository_name and username/image_name:tag. We will then use these details to automatically pull and test your project.
No Need to Run: You do not need to keep your Docker image running on your local machine for evaluation. We will pull a copy from Docker Hub, run it on our servers, and test it there.

Q27: Can we get extra credits if we use a local LLM?

A27: That’s up to Anand. I will discuss this with him in tomorrow’s meeting. Please ask this question on Discord, and I’ll bring it up in the meeting.

Q28: For Project 1, what about B tasks (B3 to B10)? How should we approach them?

A28: We will have a session specifically for B tasks, most likely tomorrow. We still have some work to do to get that ready.

Q29: What is the purpose of running the server inside a Docker image instead of directly on our local machine?

A29: Running your server inside a Docker image offers several key advantages:

Portability (Distribution): A Docker image packages your application and all its dependencies, making it executable anywhere. It doesn’t matter if the host system is macOS, Windows, or Linux; your Dockerized service will run consistently. This allows us to easily deploy and test your project on our servers.
Isolation (Safety): Docker containers provide an isolated environment. If your server code crashes, misbehaves, or contains vulnerabilities, it won’t affect or damage the host machine. This is crucial given that some tasks involve machine-generated code, whose behavior might be unpredictable.
Error Correction: If a task generates code that causes issues, the problem is confined to the container. You can simply discard the problematic container and start a fresh one without impacting your main development environment.
Reproducibility: Docker ensures that the environment your application runs in is consistent, eliminating “it works on my machine” problems.

Q30: When we create the Docker image, will it use Python 8000 port by default?

A30: Yes, inside the Docker container, your server will be listening on port 8000, as defined in the code.

Q31: What is the specific role of the dockerfile in Project 1?

A31: The dockerfile is a crucial script that instructs Docker on how to build your image. It specifies the base image (e.g., Python), copies your application files, installs dependencies (like UV), and defines the command to run your server. This dockerfile must be included in your GitHub repository for project evaluation.

Q32: How can I check which ports are currently in use on my system to avoid conflicts?

A32: You can use command-line tools to check active ports:

Linux/WSL: netstat -tulpn or ss -tulpn
Windows: netstat -ano These commands will show you all listening ports and the processes using them.

Q33: What is port mapping (e.g., 5000:8000) when running a Docker container?

A33: Port mapping creates a bridge between your host machine (your computer) and the Docker container. For example, 5000:8000 means:

8000 is the internal port inside the Docker container where your server is running.
5000 is the port on your host machine that traffic sent to will be forwarded to the container’s port 8000. This allows you to access your Dockerized server from your browser or other applications on your host machine by using localhost:5000. This allows external communication with the isolated container.

Q34: How should the arguments and functions be defined in the project structure for evaluation?

A34: For evaluation, your project should define two main functions: script_runner and task_runner.

script_runner: This function will take script_url (the URL of the script to run) and email as arguments. It will use UV to fetch and execute the script from the provided URL.
task_runner: This function will take task as a parameter. This task parameter will be a JSON object containing arguments (such as script_url and email) and a response_url. Your task_runner will then use these details to execute the specific task required.

Q35: Is the project deadline for all tasks A1-A10?

A35: Yes, you must complete all listed tasks from A1 to A10.

Q36: Will these sessions be covering the entire project in detail?

A36: We will continuously develop the project in future sessions. You’ve already seen how we’ve covered the basics today. We’ll continue this structured approach, breaking down complex aspects into manageable steps.

Q37: Can we use functions for each task, and if so, would that make the function list too large?

A37: Yes, you can use functions for each task. The trade-off is between having many small, specific functions and fewer, more generic ones. A large number of specific functions might make your code base larger, but it also increases modularity. Alternatively, you can use generative AI (LLMs) to dynamically create these functions as needed, allowing for more flexibility. This is a topic we will demonstrate in a future session.

Q38: Can you elaborate on generating code dynamically using LLMs for tasks?

A38: Yes, in a future session, we’ll demonstrate how to use LLMs for dynamic code generation. This involves:

Prompt Engineering: Carefully crafting prompts to instruct the LLM on what code to generate.
Error Correction Loop: Implementing a loop where the generated code is tested, any errors are fed back to the LLM with the context, and the LLM iteratively corrects the code until it works. This allows for highly flexible and adaptive task execution, where the LLM can generate and refine code based on specific requirements and debugging feedback.

Q39: Will the generated code from LLMs be secure, and how do we ensure it doesn’t harm our system?

A39: This is precisely why we advocate for running your server within a Docker container. The Docker isolation protects your host system from any malicious or buggy code generated by the LLM. If an LLM generates harmful code, the container acts as a sandbox, preventing it from affecting your operating system or other applications. Once the container is stopped, all its changes disappear, ensuring a clean slate for the next run.

Q40: Will sample scripts for B tasks be provided?

A40: We might provide samples for B tasks, but it’s not a certainty. I will discuss this with Anand. Please put this question on Discord.

Q41: How many API tokens are allowed for the project?

A41: You have an allowance of 25 API tokens for the project.

Q42: Will we get an extra allowance for API tokens if needed?

A42: We will discuss this with Anand. Please raise this question on Discord, and I’ll clarify it in tomorrow’s meeting.

Q43: What are the criteria for project evaluation regarding tokens?

A43: Each task execution counts as a token. Your project needs to be able to run all tasks (A1-A10) successfully.

Q44: What should be the return type if an API call is made within a task (e.g., fetch data from an API)?

A44: If an API call is made, the task should return an HTTP 200 OK response if it completes successfully.

Q45: If the API call requires authentication, will the API token be provided within the prompt or will it be handled separately?

A45: The API token for authentication will be stored in an environment variable within the Docker container. Your code will fetch it from there, so it won’t be explicitly in the prompt itself. This ensures security.

Q46: Could you clarify whether Project 1 needs to use Python 8000 or some other port, as my WSL is using port 8000 by default and it’s causing conflicts?

A46: For Project 1, your code should be configured to run on port 8000 internally within the Docker container. If port 8000 is already in use on your local machine, you should map it to a different available port on your host system (e.g., 5000:8000). This mapping (host_port:container_port) ensures your code still internally uses 8000 while being accessible from your desired host port. Before final submission, ensure your code explicitly states that it’s running on port 8000 within the Docker image, as that’s what we’ll test.

Q47: Will the submission deadline for Project 1 be postponed?

A47: I will discuss this in tomorrow’s meeting, but I don’t think it will happen for two reasons: Project 1 was released a month ago, and we are already moving the GA5 deadline, which should free up time for Project 1. I would not have high hopes for it to be postponed.

Q48: Can we request multiple postponement requests if there are several such circumstances?

A48: We will discuss such requests in tomorrow’s meeting, but I cannot guarantee a postponement for Project 1.