posit-dev / posit-dev/images-shared

Strip comments from package list files in apt.install_packages_from_file macro

Open
#550 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

cvp:2 docker tdp:2
Dominant language
Python
Stars
2
Forks
0
Avg merge
4d 13h
Merged PRs (30d)
22

Description

Problem

The apt.install_packages_from_file macro (posit_bakery/config/templating/macros/apt.j2) reads package list files raw via xargs -a:

xargs -a {{ file | trim }} apt-get install {{ global_options }} --no-install-recommends

This means downstream images cannot annotate their _packages.txt files with comments — any # … line or inline annotation becomes an attempted package name and breaks the build.

It would be valuable to let images document why each package is included so that customers extending the image know what they can safely drop from custom builds.

Proposed change

Filter out comments and blank lines before piping into xargs:

sed -e 's/#.*//' -e '/^[[:space:]]*$/d' {{ file | trim }} \
    | xargs apt-get install {{ global_options }} --no-install-recommends

This supports:

  • Block comments for grouping (# Build tools)
  • Inline comments for per-package rationale (libpq-dev # PostgreSQL headers — RPostgres, psycopg2)
  • Blank lines as section breaks
Edge case

An all-comment file would produce an empty xargs invocation. Adding xargs -r (GNU --no-run-if-empty) guards against apt-get install running with no args.

Companion change

The goss test fixtures in consuming repos use readFile … | splitList \"\\n\" to assert each line is an installed package. Those snippets also need a sprig filter (e.g. regexReplaceAll \"#.*\" . \"\" | trim) before the assertion loop, otherwise comment lines turn into spurious package assertions.

Context

Came up while expanding the optional-package lists in posit-dev/images-workbench — wanted to inline rationale for each dev-header so downstream users could prune their extensions, but the current macro design doesn't allow it.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in posit_bakery/config/templating/macros/apt.j2 and inspect how apt.install_packages_from_file builds its xargs command. Update the package-list handling for comments, inline annotations, blank lines, and empty input, then review the consuming-repository goss snippets that use readFile and splitList to ensure their assertions ignore comments. Done means annotated package lists install successfully without spurious empty invocations or package assertions.

Written by the indexing model from the issue text.

Assessment

Tech stack
shell
Domain
build-system, devops
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.