I can pretty much guarantee that the PackageName method didn't do what you thought it did.

Every Go package has a package name, specified in the package statement of its source files. This name is not unique (there are several packages with a package name of errors). This is not what the PackageName method returned.

Every Go package has an import path, which is a unique identifier of the package. If you want to uniquely identify a package, you should use this. This is not what the PackageName method returned either.

When a Go file imports a package, the imported package is assigned a name in the scope of the importing file. This name defaults to the name of the imported package, but the file doing the import can choose to rename it.

The PackageName method returned a unique local package name that we would use for references to a objects defined in a given .proto file. If a.proto and b.proto were part of the same Go package, they'd have different "package names" as defined by that function. And if c.proto imported both of those, c.pb.go would include two import statements for the same Go package, but with different local names. There was also some fun confusion where adding an import to a.proto could change the generated code in b.pb.go, even if a and b had no relation at all.

If that all sounds rather confusing...well, it was. We now use the import path to identify packages, and we treat each generated file independently when figuring out what name to assign to an imported package. And the FileDescriptor.PackageName method is gone, because the same .proto file may have different names in different generated files now.

So, that's all background. What does that mean for code that was using FileDescriptor.PackageName?

If you want a unique string that identifies the file and you don't really care what it looks like, you can replace it with this function:

func PackageName(f *generator.FileDescriptor) string {
  return fmt.Sprintf("p%p", f)
}

That's a fairly silly function, but so was the method that it replaces.

If you want a string that identifies the file's Go package, that's the import path. We don't seem to be exposing a method that returns that right now; if you want to add one, that'd be reasonable, but you probably don't need it--note that all the objects in a file (messages, etc.) have a GoImportPath method that returns the import path.

If you're doing something else, let me know what it is and I'll see if I can help.

Oh, and I should note that this PR also doesn't do what you think: I believe FileDescriptor.packageName is the actual package name of the Go package associated with the descriptor (so many descriptors might have the same name, including descriptors in packages that have the same name but different import paths). As I explained above, the old PackageName method returned a unique per-file string, which is a completely different thing.

Thank you for the detailed, thought-out explanation. It seems like the schematics have changed quite a bit. I'll do some validation on my end to see if we need to use the function you suggested or something completely different.