BookmarkSubscribeRSS Feed

My Build Script in Visual Studio Code: An Automation Pattern

Started yesterday by
Modified yesterday by
Views 83

I use the SAS Extension for Visual Studio Code for projects that also involve a mix of Python, with Python projects containing different configuration, version specifications, and package dependencies. I find installing and maintaining those artifacts cumbersome and error-prone.

 

Over time, I have developed practices that suit my working style and yield organisation, isolation and automation benefits. I execute them through a shell script which I call my “build” script. Here’s an outline.

 

Organisation

 

I have been using a Mac laptop for a long time and store several projects under a central folder called current_projects. That’s a bit of a misnomer because I am not very meticulous about archiving my folders so you find everything there happens to be “current”. Within each folder is a buildfolder. The purpose of this build folder is to:

 

  1. Hold a shell script (details follow) which executes the “build” activity
  2. Serve as a parent folder to any virtual (Python) environments I may choose to create
  3. Store configuration and other variables about the project build, such as a .env file.

 

The idea is to implement a “boring consistency”. I expect to find a buildfolder in every project folder I open and can trigger the same so that I can develop with the most relevant configuration.

 

 

Isolation

 

Projects utilise several distinct packages, some of which require a specific Python version. Attempting to install and maintain all packages in my base Python environment is foolhardy and will likely result in version and dependency conflicts. Virtual environments are useful in such situations because they help me package my solution specifications in a portable, reusable and repeatable manner. My typical build.sh contains the following.

 

 

 

Some points to note from the above script.

 

  1. I prefer uv as a Python package manager due to its faster speed compared to the standard pip utility.
  2. During development, I tend towards ephemeral environments where I build the virtual environment afresh every time I work on the project. Your preference may vary. Once I am done with development, I run this script only to execute some prepared programs ( the commented python scripts/ section) and then remove the folder altogether. Saves some space.
  3. I use jupyter-lab . To ensure my notebook accesses the right Python kernel (i.e. the one associated with the virtual environment), I use ipykernel to install a kernel pointing to the venv I created.

 

This way, irrespective of where I choose to develop, my configuration travels with my code. I can push my project to a GitHub repository, clone it from another machine (assuming I have Python of the same version installed) and run the build.sh script to create my virtual environment afresh.

Automation

 

While convenient, I’d like it even better were I not be required to remember to run this script every time I open a project. Visual Studio Code’s automation capabilities, offered through tasks, come in useful. Here’s what I need to consider when opening a project.

 

  1. The virtual environment from the last time I worked on this project might still be lingering about.
  2. Temporary folders such as __pycache__ and .ipynb_checkpoints from my previous development session need to be cleaned up.
  3. A brainwave during the night might entail adding new packages to requirements.txt
  4. And, of course, I need to remember to run the build script

 

These folders aren’t trivial and, depending on the size and number of projects, take up space on my workstation. I’d prefer to not even have my projects sit in my workstation anyways, isn’t that what GitHub is for?

 

Tasks help you automate routine activities in Visual Studio Code. Tasks can be folder-specific or workspace-specific and can call additional scripts upon certain triggers (such as opening a folder for instance). Tasks can also be sequenced.

 

Create a Python program which resides in a scripts folder in your project (you may choose to even have this reside in build but I like to keep them separate). An example is shown here.

 

 

 

This program searches for specified directories and files anywhere within the repository and deletes them. I have included common files which I do not require (since I shall probably be recreating them as I develop).

 

Next, create a folder called .vscode (it may already exist) in the root folder of your project and add a tasks.json there. If a tasks.json exists, it’s possible that you already know how to define a task and in this case, would be adding one more. Here’s the block to add to your tasks.json.

 

 

 

This is only the first task. Simply expressed, it runs every time this folder ( ${workspaceFolder} ) is opened and executes a Python program (the one above) that cleans up unwanted folders and files. Tasks can also be configured through the command palette of Visual Studio Code.

 

The second task, which you would ideally want to have run after the first task is as follows. This may also be added to the tasks list in the tasks.jsonfile above.

 

 

Once you’ve deleted unwanted files and folders, you can proceed with building the environment afresh. Note the additional options here: dependsOn and dependsOrder . dependsOn specifies that the build_environmenttask depends on the successful run of the Clean Python cache task. dependsOrder specifies that this should run in sequence, i.e. after Clean Python cache. The final tasks.json is as follows.

 

 

 

Test this by closing (File -> Close Folder) and then reopening the project folder. Be prepared to show a little patience the first time as waiting for the task to complete may take some getting used to.

 

 

(view in My Videos)

 

 

Be aware of the tradeoffs. Depending on their complexity, tasks may run for some time and you may need to wait a short while after opening the folder to commence your work. Also, some projects with complex dependencies and heavy packages might be better off left alone without having to rebuild them every time. Your configuration is a carefully crafted context-contingent choice.

Creating a build script enables rapid experimentation and development and provides you repeatability and portability benefits. For a starter script, refer this GitHub repository and feel free to provide your suggestions in the comments section.

 

GitHub repository: https://github.com/SundareshSankaran/build-script

Contributors
Version history
Last update:
yesterday
Updated by:

Catch up on SAS Innovate 2026

Nearly 200 sessions are now available on demand with the SAS Innovate Digital Pass.

Explore Now →

SAS AI and Machine Learning Courses

The rapid growth of AI technologies is driving an AI skills gap and demand for AI talent. Ready to grow your AI literacy? SAS offers free ways to get started for beginners, business leaders, and analytics professionals of all skill levels. Your future self will thank you.

Get started

Article Tags