commitizen icon indicating copy to clipboard operation
commitizen copied to clipboard

manage other file type in `version_file`

Open 12rambau opened this issue 1 year ago • 11 comments

Description

I'm working on a widget lib called ipyvuetify and I would like to use commitizen to help us manage the releases. Problem as the ipywidget libs are at the frontiere between pure python and javascript we do embed to version number in other file type than .py, specifically .json

Possible Solution

would it be possible to add support for .json file. It would use the same pattern as the one use in .py files:

"package.json:ipyvuetify.version"

would look into a pakage.json file and replace the ipyvuetify.version key.

12rambau avatar Aug 24 '23 21:08 12rambau

Hoy can either build your own provider: https://commitizen-tools.github.io/commitizen/config/#custom-version-provider

Or a good way to start is to use the version files setting: https://commitizen-tools.github.io/commitizen/bump/#version_files

woile avatar Aug 25 '23 04:08 woile

As I was mentioning in my issue my problem is simply managing other file types. I'm well aware of the custom-provider and I use version_files setting in all my projects to update version number in conf.py (sphinx docs settings).

As .json is a common file type and not so unusual in python packages I was proposing to extend the current scope of version_files for all commitizen users. If it's a wanting feature I'm happy (as usual) to propose a PR.

If for some technical/design reason, you don't want to include it, no problem.

12rambau avatar Aug 25 '23 07:08 12rambau

Sorry, I think I don't get it, would you mind elaborating with some examples?

woile avatar Aug 25 '23 07:08 woile

sure:

the build of an ipywidget lib requires to build both a python lib and some javascript package that will be send to jupyter tool to inject JS/css compiled stuff to the interface. In our case we have 3 json file that should be wired to the version number like this package.json file:

{
  "name": "jupyter-vuetify",
  "version": "1.8.10",
  "description": "Jupyter widgets based on vuetify UI components",
  "license": "MIT",
  "author": "Mario Buikhuizen, Maarten Breddels",
  "main": "lib/index.js",
  "repository": {
    "type": "git",
    "url": "https://github.com/widgetti/ipyvuetify.git"
  },
  //...
}

That would make our lives much easier if we could set up in the version_files parameter the following string: "package.json:version" to update the key in the dictionnary for each release. at the moment my understanding is that version_files only manage .toml and .py files.

12rambau avatar Aug 25 '23 08:08 12rambau

version_files is for any file. But it traverses the file line by line and you can use a regex to find the match, in your case, if you are using the .cz.toml or pyproject.toml, you'd do:

version_files = [
  "package.json:version"
]

where pacjkage.json is the file you want to modify, and the version is the regex matching any line containing the string "version", the colons : separate the file from the regex

woile avatar Aug 25 '23 08:08 woile

image

ok then I was millions of kilometers away from understanding how version_files was working.

If it's regex and multiple "version" keys exist in the package.json, I assume there is no way for commitizen to make the understand right ?

12rambau avatar Aug 25 '23 09:08 12rambau

Unfortunately as of now it's one line at a time, so more complex regex are not possible. IIRC we had multi line support but we had troubles with it and went back to per-line. Maybe @Lee-W remembers more

woile avatar Aug 25 '23 09:08 woile

I see why this approach is perfectly fine with unstructured files like .py or .txt but I think it could be improved for configuration files. Out of my mind I see .cfg, .toml, .yaml, .json that would clearly benefit from a finer tool.

What prevents any of the tools available in my .toml to have a "version" key ? same for .json. What if the current behaviour remain the default one and for the said dict-like config file you search for keys to replace the value ?

12rambau avatar Aug 25 '23 10:08 12rambau

In principle, you can achieve that with a custom "version provider" specifically design for your application.

Version providers are plugins, that can be implemented as new python packages. You just have to register them in setup.py or pyproject.toml and after being installed, commitizen will detect them.

See this upcoming fix for the npm provider, which modifies multiple files: https://github.com/commitizen-tools/commitizen/pull/813/files#diff-e8332acd33dab58c4ebb73f2c69b289b06ec6112349475a1e479fc9fb53ee688

You could extend the existing poetry provider, and also access your json files.

You can see how to create one here: https://commitizen-tools.github.io/commitizen/config/#custom-version-provider

Alternatively, because providers can access the config of commitizen, you could implement a ConfigVersionProvider, and add new keys to the commitizen section.

[tool.commitizen]
# ... some other stuff
version_provider = "config"  # existing commitizen setting
config_version_source="pyproject.toml>tool.poetry.version"  # new setting which you would use for configversionprovider
config_version_updates=[  # new setting which you would use for configversionprovider
  "foo/package.json>name.version",
  "bar/chart/Chart.yaml>name.version",
]

What do you think of this approach?

woile avatar Aug 25 '23 17:08 woile

I'll try to implement it and come back to you if I manage to make somthing work ;-) thanks for your time

12rambau avatar Aug 25 '23 18:08 12rambau

Unfortunately as of now it's one line at a time, so more complex regex are not possible. IIRC we had multi line support but we had troubles with it and went back to per-line. Maybe @Lee-W remembers more

Yes, you're right. I think that's all the context I have as well. Looking forward to seeing whether we can add it back without issue in the future

Lee-W avatar Aug 26 '23 05:08 Lee-W