Adding options for fragments/types

[zerothi]

The fragments currently only has 3 keys:

• name
• check
• showcontent

However, the format of several details of the fragment is controlled by some top-level keys.

• issue_format
• all_bullets
• possibly more

Would towncrier accept a PR where (at least the above two) are allowed in the fragments, but fallback to the global values?

My main motivation is that separate fragments can require special formatting in terms of issues.

[adiroiban]

Hi Nick, THanks for the report.

I am not sure what feature is requested here.

Can you provide a full example of input files and the expected output vs the actual output?

Cheers

[zerothi]

I could imagine something like this:

[tool.towncrier]
issue_format = ":issue:`{issue}`"

    [[tool.towncrier.type]]
    directory = "highlight"
    name = "Highlights"
    showcontent = true
    issue_format = ":pull:`{issue}`"

 ...

and now all fragments that are highlights, are outputting:

  (:pull:`865`)

while all other show:

  (:issue:`865`)

It allows some more customization, at very little confusion.

Sorry for not expanding anymore, I hope this is OK?

[adiroiban]

We can go with that.

---

What do you think of a different approach.

Instead of defining various formats in the configuration file, why not implement them via Jinja2 insite a custom template?

This will require that we expose the "raw" data to Jinja2, instead of sending the already rendered line.

But I hope that with that, you can implement any customization that you can think of :)

[zerothi]

...
What do you think of a different approach.

Instead of defining various formats in the configuration file, why not implement them via Jinja2 insite a custom template?

This will require that we expose the "raw" data to Jinja2, instead of sending the already rendered line.

But I hope that with that, you can implement any customization that you can think of :)

Sounds like a much bigger effort than I had planned ;)

Ideally, I can see why this might be the way forward. But so far, that requires quite a bit of restructuring, with a major problem in ensuring backwards compatibility. So if you want this, I would say maintaining backwards compatibility might be problematic...

[adiroiban]

Hi Nick,

Your suggestion with custom issue_format configured for a fragment type is nice and clean.
I am happy to review and approve a PR for it.

---

In terms of backward compatibility for exposing more data to the templates.
We can keep the current default template and the current pre-renderd issue line.

The extra data will be used only by custom tempates.