← Back to issue list

no way to differentiate between build-time and run-time env vars in plugins

View original Launchpad issue

Metadata

Project
snapcraft (launchpad)
Number
#1600035
Type
issue
State
open
Author
~thomir-deactivatedaccount
Labels
—
Created
Updated
Closed
—

Current evaluation

Feature request to differentiate build-time vs run-time environment variables in plugin BasePlugin.env() method. Issue is 10 years old with no maintainer engagement or comments.

Suggested action: close stale

Reason: The issue is 10 years old (3709 days) with zero maintainer interaction, no labels, and no comments. craft-parts has undergone significant architectural evolution since then, including new plugin systems and environment handling features (e.g., PR #1608 'allow applications to set build environment'). The reported limitation is likely no longer applicable to the current plugin architecture.

Impact: 50 Quick Win: 30.0 Staleness: 95 Complexity: 40 Confidence: 65 Support Request: 30

Issue body

As far as I can tell, BasePlugin has one method for manipulating environment variables: the env() method. I have a custom plugin where I need to be able to set certain environment variables at build-time, so I'm setting them in this method like so: ``` def env(self, root): env = super().env(root) env.extend([ 'CPPFLAGS="-std=c++11 -I{} $CPPFLAGS"'.format(os.path.join( root, 'usr', 'include')), 'CFLAGS="-std=c11 -I{} $CFLAGS"'.format(os.path.join( root, 'usr', 'include')), ]) return env ``` This works fine for building the snap, but I notice that these environment variables are then present in the command wrapper as well, so they're also being set for runtime. Most of the time this won't be a massive issue - setting CPPFLAGS has no effect at run-time, but it's a little surprising, and I can imagine situations where plugin authors will want more control over what's set at build time, and what's set at run-time.

Evaluation history

Date Model Scores Action Summary
qwen3.6-35b-a3b-mtp-q6
Impact: 50
Quick Win: 30.0
Staleness: 95
Complexity: 40
Confidence: 65
Support Request: 30
close stale Feature request to differentiate build-time vs run-time environment variables in plugin BasePlugin.env() method. Issue is 10 years old with no maintainer engagement or comments.
qwen/qwen3.6-35b-a3b
Staleness: 95
Complexity: 15
Confidence: 85
Support Request: 5
needs triage Feature request to separate build-time and run-time environment variables in plugins. Currently, the env() method applies variables to both phases. Untriaged, zero maintainer comments, and over 10 years old.
qwen/qwen3.6-35b-a3b
Staleness: 95
Complexity: 65
Confidence: 85
Support Request: 10
close stale Feature request to separate build-time and runtime environment variables in plugins. Currently, a single env() method applies to both phases. Unlabeled, no maintainer response, inactive for over seven years.
qwen3.6-35b-a3b-mtp-q6
Staleness: 95
Complexity: 65
Confidence: 85
Support Request: 10
needs triage Plugin env() method applies environment variables to both build and runtime contexts. No maintainer response after over a decade. Lacks labels and formal assessment.
qwen3.6-35b-a3b-mtp-q6
Staleness: 98
Complexity: 60
Confidence: 92
Support Request: 10
close stale BasePlugin.env() applies environment variables to both build and runtime without differentiation. Plugin authors need separate control for build-time versus runtime variables. The issue is open, unassigned, and requires triage.

Update history

No update history recorded yet.

Related work

  • Likely Fixed By: craft-parts#1608 (confidence 60%)

    PR #1608 added build environment customization capabilities, which may address the original concern about separating build-time from run-time environment variables.

Related issues

No related issues found above the similarity threshold.