[Documentation] Commitizen and questonary using different prompt names

[Zylvian]

Type

• Conent inaccurate
• Content missing
• Typo

URL

https://commitizen-tools.github.io/commitizen/customization/

Description

I'm working on my own commitizen template, and the only used options in the pre-existing templates are "input", "list" and "confirm", and the two first differ from the questionary equivalents "text" and "select",

Therefore, as the documentation for questions reads type - The type of questions. Valid type: list, input and etc. See More, I don't know what type of input to use if I for example want to use questionary's "autocomplete" query.

[woile]

Hello! Here's the list from questionary available prompts: https://github.com/tmbo/questionary/blob/master/questionary/prompts/__init__.py#L9

list and input are possible values, I think questionary now prefers select and text as you mention, but questionary allows them.
It all come down to the first library we were using, but long story short, questionary allows those values. Of course you can use the new ones, but I'd stick to the ones we have.

As you mention it would be worth documenting which ones we recommend, in case we have to migrate to something else, we will maintain the ones we have now.

[Zylvian]

Hi, thanks for the response!

I need some of the new feature for a commitizen template I'm working on atm, and a few of the features would be handy as well, such as skipping questions: cli/cli#297 (comment)

Since you guys implement questionary, I assume that I could make use of the same 'questions' formatting, and therefore can include stuff like validators. Would you not recommend this on the chance that you would swap dependencies in the future?

[woile]

Even if we change dependencies, I would keep the same interface of questionary, so your package shouldn't have any problems in the future.
So I'd say you can include your validators safely 👍

[Zylvian]

With the help of the newer questionary additions, I've written an adjusted template. It uses the checkbox feature for specified scopes, as well as an extra field which grants issue closing autocomplete.

To improve it, I have a few general questions, as it seems you've worked with both:

1. Fetching issues from private repos obviously requires Git authentication. I'm currently implementing 2 methods - one which is using keyring to look for the local access token, and one backup for fetching and saving the access token in the venv. Would you have any other better additions?

2. I'd love for the autocomplete to work in the middle of the footer. Would there be some sort of way that you know of to add in the autocomplete function in the middle of the footer parsing, or should I take it to a prompt_toolkit forum?

[woile]

Hey sorry for the late reply.

1. Fetching issues is an API call, so using the git ssh wouldn't be possible. You could use the same git password to encrypt the access token. You could do it with fernet. Or just save the access_token back in the keyring: keyring.set_password("commitizen", "access_token", current_access_token). If it expires you'll have to check that and query the git provider for a new token.

2. I don't know to be honest, better to ask to prompt_toolkit people.