RFC: valid identifiers #40
The decision to allow '.' feels somewhat arbitrary but I feel is easily justifiable from the standpoint that it is often used for CI/CD related things like version numbers or a DNS name identifying a deploy target. It is also one of the few allowable special characters that does not require any additional URL encoding. Signed-off-by: Alex Suraci <email@example.com>
I’m pretty wary of this change. First, I am sympathetic to the technical challenges that arbitrary naming has to parsing and other programmatic processing of the identifiers; it’s a bear and having an unambiguous syntax is not only useful, but preferable.
However, the strict limitation of only Unicode characters plus a pair of word separators (side note, it’s nearly impossible to find a concise listing of what counts as a Unicode “letter”) is a massive regression in visual differentiability. Take the following examples from my own pipelines which contain a great many, very similar resources often times based on different artifacts from the same root project.
Compare those names to an equivalent with an idealized set of names
Or even a slightly sanitized version I’ve used (because it’s not just that
Both of the latter two options are more understandable both in what “type” (dependency, module, package) they are as well as what they refer to (https://github.com/paketo-buildpacks/azure-application-insights)
A display name (now removed from the RFC) is one option here, but I think it’s likely nearly redundant for many identifiers where the majority of characters would be identical, but certain separator characters would be subbed back in for dashes; not a very satisfying way of writing pipeline definitions.
Instead I’d propose that the character set should be loosened to include the common separator characters that are not ambiguous and problematic in the way that
@nebhale Good point! I don't think super-long-pipeline-names-with-embedded-values is a pattern we really want though - it feels more like a workaround in absence of proper grouping and labeling, which is what instanced pipelines (#34) intends to achieve:
$ fly get-pipeline -p dependency -i repo:github.com/paketo-buildpacks/azure-application-insights
I'll update the RFC to mention this.