'charm create' produces metadata.yaml that error with 'charm proof'

[erik78se]

• Used: charm create, charm proof
• Version of charm: 2.5.2

What version am I running?

snap info charm
name:      charm
summary:   charm and charm-tools
publisher: Cory Johns (johnsca)
contact:   [email protected]
license:   unset
description: |
  charmstore-client and charm-tools
commands:
  - charm
snap-id:      2Rryoc2ylScfbFl4eQtpntHD9iuZuMvt
tracking:     stable
refresh-date: 23 days ago, at 17:26 CET
channels:
  stable:    2.5.2                2019-02-07 (320) 47MB classic
  candidate: 2.5.2                2019-02-07 (320) 47MB classic
  beta:      2.5.2                2019-02-07 (320) 47MB classic
  edge:      2.5.2+git-3-gef3d9a6 2019-02-12 (326) 47MB classic
installed:   2.5.2                           (320) 47MB classic

I am using: Distributor ID: Ubuntu Description: Ubuntu 18.04.1 LTS Release: 18.04 Codename: bionic

Issue

I create a new charm with:

charm create -t bash hookmissingcharm"

My intention is to have NO interfaces / relations for this charm. E.g. no provides, requires or peers sections in metadata.yaml

When I try to figure out if the charm is OK or not with charm proof, it will indicate that this charm has problems. Messages that makes no sense at to me and provides no hints on whats actually going on:

$ charm proof
I: `display-name` not provided, add for custom naming in the UI
I: Includes template icon.svg file.
W: no copyright file
E: template interface names should be changed: interface-name
I: relation provides-relation has no hooks
E: template interface names should be changed: interface-name
I: relation requires-relation has no hooks
E: template interface names should be changed: interface-name
I: relation peer-relation has no hooks

I expected the following

• The 'charm proof' produce better help or indication on whats wrong with the situation if my charm has no relations/interfaces defined in metadata.yaml.

• The generated metadata.yaml is populated with information that the relations may be removed if not used. Something like this (metadata.yaml).

name: hookmissingcharm
summary: foo
maintainer: Erik Lnroth <Erik.Lnroth@juju-dev>
description: |
  <Multi-line description here>
tags:
  # Replace "misc" with one or more whitelisted tags from this list:
  # https://jujucharms.com/docs/stable/authors-charm-metadata
  - misc

# Remove below this line if your charm isn't going to relate to anything.
subordinate: false
provides:
  provides-relation:
    interface: interface-name
requires:
  requires-relation:
    interface: interface-name
peers:
  peer-relation:
    interface: interface-name

What I got

$ charm proof

I: `display-name` not provided, add for custom naming in the UI
I: Includes template icon.svg file.
W: no copyright file
E: template interface names should be changed: interface-name
I: relation provides-relation has no hooks
E: template interface names should be changed: interface-name
I: relation requires-relation has no hooks
E: template interface names should be changed: interface-name
I: relation peer-relation has no hooks

[johnsca]

The templates are intended as a starting point and you are expected to have to make changes to it before it can be considered a functional charm, so it doesn't seem unreasonable for it to complain when you don't make those changes. I think the original goal was to ensure that the files containing the minimal starting data were manually touched at least once after starting from a template so that we didn't end up with many charms in the store all using the same placeholder data. And, given that, the error message, "template interface names should be changed", seems relatively clear to me, but maybe something like "interface data generated in the template should be changed before use" would be a bit clearer?

On the other hand, maybe an even kinder starting point would be to only include example data in the metadata.yaml in the form of comments, rather than actual non-functional yaml that needs to be changed. Then, instead, proof would just complain that the file is empty and that the data needs to be filled in, maybe with a hint that examples can be found in the comments in the file.

[erik78se]

On the other hand, maybe an even kinder starting point would be to only include example data in the metadata.yaml in the form of comments, rather than actual non-functional yaml that needs to be changed. Then, instead, proof would just complain that the file is empty and that the data needs to be filled in, maybe with a hint that examples can be found in the comments in the file.

Thats alot better I think. I'm trying to lower the bar to get into the charming, that's why I'm bombing you on these matters.

[ahmedbutt7121991]

remove below lines from metadata.yaml file subordinate: false provides: provides-relation: interface: interface-name requires: requires-relation: interface: interface-name peers: peer-relation: interface: interface-name

[JoseCarlosNF]

@erik78se Did you got make charm work?

I'm have problems with hooks.

I used default template (reactive-python)

    charm create layer-example

after change files, removing de relations, when i try deploy on juju not working. The error output is

    `ERROR invalid charm "layer-example": has no hooks nor dispatch file` 

Any tips on what should be done? Shouldn't the template have the necessary hooks, as in other templates?

[JoseCarlosNF]

I detected that it was just a beginner's mistake.

I was trying to deploy without setting the absolute path to the directory with the build result.

But that brought me to another question. Since I set up an environment variable, for the local build directory, this shouldn't be a problem, right?

[johnsca]

So, charm create is now deprecated in favor of charmcraft init, which will get you started with a charm based on the Operator framework for charms which is the replacement for the Reactive framework for charms.