Hi! This happens to me as well. Would it be possible to prefix the class names with the parent(s) to avoid name collisions?

E.g.

spec.template.spec

would become

class Spec

class SpecTemplate

class SpecTemplateSpec

I don't know the problem space well enough. Are you sure these are always separate classes? Can they be the same class, but with fields that can be omitted? A more Pkly thing could be to have separate modules for First and Second, in which case you already have First.SomeClass "externally," without adding repetitive verbosity to internal use.

did this fix it?
#20

I ran into this issue today with trying to convert Elastic Cloud on Kubernetes (ECK) CRDs to PKL.
Here is the command I ran:

pkl eval package://pkg.pkl-lang.org/pkl-pantry/[email protected]#/generate.pkl \
   -m . \
   -p source="https://download.elastic.co/downloads/eck/2.12.1/crds.yaml"

Converting the pkl file back to yaml gives the following error:

# pkl eval Elasticsearch.pkl
–– Pkl Error ––
Duplicate definition of member `Spec`.

142 | class Spec {
      ^^^^^^^^^^
at co.elastic.k8s.elasticsearch.v1.Elasticsearch (file:///root/venv/eck/pkl/test/Elasticsearch.pkl, line 142)

I have the same problem:

$ pkl eval "package://pkg.pkl-lang.org/pkl-pantry/[email protected]#/generate.pkl" -m . -p source="https://raw.githubusercontent.com/crossplane/crossplane/master/cluster/crds/apiextensions.crossplane.io_compositions.yaml"

$ pkl eval Composition.pkl

–– Pkl Error ––
Duplicate definition of member `String`.

370 | class String {
      ^^^^^^^^^^^^

also the generated class name "String" is not ideal

I don't know the problem space well enough. Are you sure these are always separate classes? Can they be the same class, but with fields that can be omitted? A more Pkly thing could be to have separate modules for First and Second, in which case you already have First.SomeClass "externally," without adding repetitive verbosity to internal use.

I believe this would be a great solution. Though I think the decision on when and where to create a seperate module should not be made automatically.

Maybe similarly to converters we could decide for which paths a seperate module should be created?

createModules {
  ["foos.v1.example.com"] {
    new List("first")
    new List("second")
  }
}

or a more complex Example the Kubernetes Deployment if it were a CRD:

createModules {
  ["deployments.apps.api.k8s"] {
    [new List("selector")] = "LabelSelector"
    [new List("spec", "template")] = "PodTemplateSpec"
    [new List("spec", "template", "spec")] = "PodSpec"
    [new List("spec", "template", "spec", "imagePullSecrets")] = "LocalObjectReference"
    [new List("spec", "template", "spec", "securityContext", "seLinuxOptions")] = "SELinuxOptions"
    // and so on.
  }
}

So a CRD of a Deployment would contain these Modules:

• PodTemplateSpec
• PodSpec
  • LocalObjectReference
  • SELinuxOptions
  • ... and many more...

In case it helps someone else:
I just implemented @FredrikAugust's suggestion as a workaround in my local environment.

I replaced

let (typeName = determineTypeName(path, path.fold(List(), (res: List<String>, el: String) -> res.add(el.capitalize())).join(""), accumulator.values.toSet(), 0))

which generates beatiful class names like SpecEnvironmentEnvironmentConfigsEnvironmentConfigSelectorMatchLabelsMatchLabel

@Avarei, have you considered submitting a PR with that ^ fix?