RFC: valid identifiers

[vito]

Rendered

Prior discussion: concourse/concourse#3985

[ari-becker]

For my personal circumstance, I don't need this; however, supporting a display name is probably a requirement to provide an upgrade path for a lot of users. People get attached to their personal preferences and you risk admins facing internal political wrath in their organizations over minor quibbles like this.

[topherbullock]

This would break Christmas
https://twitter.com/topherbullock/status/950411039954399232

You're a mean one, Mister @vito

[nebhale]

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.

dependency-github.com-paketo-buildpacks-azure-application-insights
module-github.com-paketo-buildpacks-azure-application-insights
package-github.com-paketo-buildpacks-azure-application-insights

Compare those names to an equivalent with an idealized set of names

dependency:github.com/paketo-buildpacks/azure-application-insights
module:github.com/paketo-buildpacks/azure-application-insights
package:github.com/paketo-buildpacks/azure-application-insights

Or even a slightly sanitized version I’ve used (because it’s not just that / is a problem, it’s totally broken in parts of fly)

dependency:github.com|paketo-buildpacks|azure-application-insights
module:github.com|paketo-buildpacks|azure-application-insights
package:github.com|paketo-buildpacks|azure-application-insights

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 / is. There is some concern about the need to quote in a terminal, but that’s a common practice that is familiar to all terminal users and doesn’t feel like a concern that a primarily server-side and web-interfaced application should be ranking strongly.

[vito]

@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. 🙂