skip_packman isn't a great config name

[jmuk]

When a user writes their own artman configuration yaml, normally they will refer to existing file, and many of existing package yaml contains 'skip_packman' for Ruby and Node.

The problem is that nobody outside of our team would understand what packman is, therefore they will copy 'skip_packman: true' line unintentionally.

It's better to rename this.

[jmuk]

cc: @geigerj @swcloud

[geigerj]

Possible suggestions for renaming: package_metadata, standalone_package, package?

[jmuk]

some random ideas: 'generate_package_files', 'source_only'

[jmuk]

package_metadata might be good. I like it.

[jmuk]

cc: @bjwatson too

[garrettjonesgoogle]

@pongad added a new config field into the GAPIC yaml named domain_layer_location which I think could serve for this purpose. The real "data" is if there is a domain layer for the API; the skip_packman field is just a specific action that should be taken as a result. The challenge is that the config line is in GAPIC yaml instead of artman yaml. Over time, I think we will be encountering more configuration like this, where the language+API-specific information needs to be used both by the generator and also outside of the generator (in the artman process).

[swcloud]

There will be always arguments around names. :)

'domain_layer_location' sounds non-intuitive too if that's a configuration item exposed to a user.

[swcloud]

In this particular case, I'd prefer 'generate_package_metadata' since it explicitly indicates whether we want to generate package metadata or not.

[jmuk]

Want to revisit this issue. Since parts of package generations are moving to toolkit, the name skip_packman does not make much sense.

[ethanbao]

The whole skip_packman has been deprecated in the new artman config syntax.