rfcs icon indicating copy to clipboard operation
rfcs copied to clipboard

RFC: Change environment variable delimiter default value

Open sgaist opened this issue 10 months ago • 7 comments

Related to https://github.com/buildpacks/spec/issues/285

sgaist avatar Mar 12 '25 16:03 sgaist

Maintainers,

As you review this RFC please queue up issues to be created using the following commands:

/queue-issue <repo> "<title>" [labels]...
/unqueue-issue <uid>

Issues

(none)

buildpack-bot avatar Mar 12 '25 16:03 buildpack-bot

@hone would you mind stewarding this one through?

jabrown85 avatar Apr 10 '25 14:04 jabrown85

@sgaist we discussed this in our last working group session, and I'm afraid we've decided that the backwards-incompatibility, or breakage of existing buildpacks, is too significant for us to move this forward. We'd be happy to discuss some alternatives, but we think it's important not to break existing buildpacks.

jkutner avatar Jul 09 '25 16:07 jkutner

@jkutner Hi! Did this discussion take into account that my analysis showed no buildpacks in the wild that would be affected? https://github.com/buildpacks/rfcs/pull/326#discussion_r1992053122

I really do think we should proceed with this change in some form - even if it's to output an explicit error in the "no delimiter specified" case (which would help with any concern about people missing this in the specification release notes).

edmorley avatar Jul 09 '25 16:07 edmorley

Stated previously but to reiterate if it got lost in the fold: I would rather the absence of this file raise an error that is opt-out instead of the current behavior. That's how strongly I believe this API is broken.

schneems avatar Jul 11 '25 13:07 schneems

@jkutner Please can this be reopened. I don't feel it was rejected in a fair way (since it occurred in a sync meeting without our involvement, rather than as a discussion on this async and open PR) - and we've also had no confirmation that the data I provided against one of the objections here was even discussed at the meeting.

edmorley avatar Sep 15 '25 08:09 edmorley

I’ve got an in progress (not submitted) PR to issue a warning from lifecycle when this condition happens. We can pair that with a (yet to be proposed) pack feature that exits non-zero on any warning to effectively make this behavior an error. Alternatively we make a new RFC to make this footgun into a proper error.

schneems avatar Sep 15 '25 23:09 schneems