Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

manage other file type in version_file #825

Open
12rambau opened this issue Aug 24, 2023 · 11 comments
Open

manage other file type in version_file #825

12rambau opened this issue Aug 24, 2023 · 11 comments
Labels
issue-status: wait-for-implementation maintainers agree on the bug / feature type: feature A new enhacement proposal

Comments

@12rambau
Copy link
Contributor

12rambau commented Aug 24, 2023

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.

@woile
Copy link
Member

woile commented Aug 25, 2023

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 woile closed this as completed Aug 25, 2023
@12rambau
Copy link
Contributor Author

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.

@woile
Copy link
Member

woile commented Aug 25, 2023

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

@woile woile reopened this Aug 25, 2023
@12rambau
Copy link
Contributor Author

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.

@woile
Copy link
Member

woile commented Aug 25, 2023

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

@12rambau
Copy link
Contributor Author

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 ?

@woile
Copy link
Member

woile commented Aug 25, 2023

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

@12rambau
Copy link
Contributor Author

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 ?

@woile
Copy link
Member

woile commented Aug 25, 2023

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?

@12rambau
Copy link
Contributor Author

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

@Lee-W
Copy link
Member

Lee-W commented Aug 26, 2023

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 Lee-W added type: feature A new enhacement proposal issue-status: wait-for-implementation maintainers agree on the bug / feature and removed issue-status: needs-triage labels Sep 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
issue-status: wait-for-implementation maintainers agree on the bug / feature type: feature A new enhacement proposal
Projects
None yet
Development

No branches or pull requests

3 participants