[Question] Kpt pkg name and dir name

[bharathkkb]

Per kpt docs

The name of a package is given by its directory name. Since the Kptfile is a KRM resource and follows the familiar structure of KRM resources, the name of the package is also available from the metadata.name field. This must always be the name of the directory, and kpt will update it automatically when forking a package

What is the reasoning behind this requirement? From my experimentation it seems like if a local destination is not specified, kpt uses the upstream directory name (rather than package name) to create the local directory and updates the forked pkg name to match.

For context some blueprint packages have diverged from this requirement and we were thinking about realigning if Kpt requires this.

[droot]

This must always be the name of the directory.

I don't remember this being a requirement. @frankfarzan @mortent Do you guys remember the reasoning behind this ?

[frankfarzan]

I would flip the question: What's the use case for having the Kptfile resource name be different from the directory name given there's a one-to-one relationship? Why is having this degree of freedom leading to a discrepancy desirable?

[bharathkkb]

@frankfarzan One reason is when directories are nested, there is context when browsing the catalog. For instance, if a user is viewing /catalog/hierarchy/simple, it is apparent simple is in context of hierarchy. However if the package name is simple, it is hard to understand that context. OTOH if we rename the dir to simple-hierarchy it seems repetitive when browsing.

[frankfarzan]

As you point out, the context is provided by the package identifier and not the name. Using your example, the identifier on local filesystem is catalog/hierarchy/simple. And once you commit this to Git, the URI for the package is then something like https://github.com/foo/bar.git/catalog/hierarchy/simple. The package name (i.e. the dirname) is not unique and doesn't provide the context you're looking for as it needs to be qualified. This is similar to how packaging works in other tools such as Golang.

I guess why I don't fully understand is: When browsing the package locally or on Git, why can't you look at the package path to give this context?

[morgante]

We have a clear use case for having better names, as @bharathkkb described above. While the info is also in the path, the path also includes "catalog/" which is not semantically important. There's no way for a human or machine to easily scan for the necessary info in the path.

@droot As the TL here, can you provide an explanation of why Kpt needs to force the directory name match?