Incorporate --version-files flag to cz bump instead of hard-reading it from the config

Description

Bump mechanism requires version to be in multiple files.

Possible Solution

Incorporate --version-files flag to cz bump instead of hard-reading it from the config.

Here we can see that version_files is directly read from the settings: https://github.com/commitizen-tools/commitizen/blob/14b6c382ff96e37ba118ba1b75073b0d2313ee91/commitizen/commands/bump.py#L86

I see that Bump has a parameterless __call__, which may complicate things. I was thinking about extending it with an own class in a script, but again I would really like to keep open the chance of using the commitizen-action if possible.

Any suggestions? Maybe I’m missing the obvious? Thanks again and cheers, Andres

Additional context

Hi everyone! Python user here. Commitizen is amazing. I have a feature request regarding the bump command.

In Python it is usually not straightforward to keep the version in a unique place, for several reasons. Many just don’t, but in my case I really would like to keep it that way for several reasons. I decided to go for this approach of having the metadata in a python file that is part of the package but can be easily parsed. That is the only place with the version, and so far all systems are working.

The problem comes when I want to auto-bump using commitizen. This seems to require a config file in the repo root (.pyproject.toml) and a set of hardcoded values with it. I would rather avoid that. See “possible solution” for more details.

Related Issue

[woile]

No problem, I understand what you mean, I also prefer explicit interfaces, everything else in the code is mostly explicit, no moving parts. Commands and configs are not the easy part of the source code I agree, working with configs is also not easy haha (we have a refactor in progress but with no deadlines).

To me, both are just part of the same parameter list, and I don’t care where they come from

But that’s the place where we specifically need to merge and where we do care where things come from. The original intention was not to be inherited, I tried to keep it simple, we needed a place where these things happened:

1. collect data from different sources (init), config and arguments parsed, skip some, etc.
2. combine the moving parts (call)

If you move point 1 outside the command Bump, where do you move it and still make it easy to understand what needs to be collected for this particular command? Better approaches are more than welcome.

To expand a little more: apart from uniqueness location I would like the version number to be a part of the Python code. Also, the module cannot be imported from setup.py to avoid race conditions. This IMO leaves very little room but it works OK. Like you, I’m also concerned about people forgetting to update. This gets only worse the more places the version is in. You could argue that CZ checks automatically for consistency, but (maybe this is where my use case diverges) I am working on templated repositories via cookiecutter and then you still have the problem of forgetting to add all the sources into the template, or editing the project afterwards. Unique location is the only way to sleep peacefully in my book.

Yes, but the problem is over time, not over the number of locations, you can accept a threshold of errors, maybe once or twice, when you are building the “template”, you can forget, until you fill them all, this is not the real issue to me. By over time I mean, if different people have to update different versions in an undefined period, you’ll have more and more chances of people forgetting, with commitizen, you remove that task from humans. Communication is also important: “hey teams, do not update the version, don’t even think about it”

You are adding code for each location where VERSION must be used, the more code -> the more bugs. I’d rather not think about race conditions. Instead of coding those parts, commitizen “proposes” to track them in .cz.toml.

I like this quote from Sandi Metz [0]:

duplication is far cheaper than the wrong abstraction

Think about maintaining and fixing, imagine if someone has to fix a bug in the I/O operations to read the VERSION vs just updating the string from wrong version to good version.

But yes, it’s quite opinionated, of course I’d like it to be more like a generic tool, but it’s a heavier burden. I hope anything I said was useful haha and feel free to discuss everything, no issue at all 👍

[andres-fr]

Hi @Woile, thanks for your detailed thoughts.

To expand a little more: apart from uniqueness location I would like the version number to be a part of the Python code. Also, the module cannot be imported from setup.py to avoid race conditions. This IMO leaves very little room but it works OK. Like you, I’m also concerned about people forgetting to update. This gets only worse the more places the version is in. You could argue that CZ checks automatically for consistency, but (maybe this is where my use case diverges) I am working on templated repositories via cookiecutter and then you still have the problem of forgetting to add all the sources into the template, or editing the project afterwards. Unique location is the only way to sleep peacefully in my book. I totally reckon that this is in the first place a problem with Python packaging and not with CZ.

Regarding your proposed solution, I don’t think it quite solves it. I mean, if we get down to Python, this can already be solved via inheritance without modifying the lib.

A quick side-rant that you can totally ignore: I personally prefer explicit interfaces instead of passing “config” objects around since they create dependencies between interface and implementation, and IMO that difficults to add features like this one in a clean way. For example, in this case Bump requires a Config object and an arguments dictionary. To me, both are just part of the same parameter list, and I don’t care where they come from. But I have no easy way to know what interface I’m expected to fulfill. BaseConfig lacks implementations for required methods and TomlConfig has dependencies that I don’t want, like file I/O. If I had an exposed parameter list, I wouldn’t have to

1. Figure out what is the actual interface that I have to satisfy in my particular case
2. Implement my own class, making sure that it provides methods for things that I may/may not know or need.

But I understand and respect that this is a matter of taste and paradigm, I can roll with that. Please don’t take this as bashing, I really think CZ is an amazing tool, I am using it daily and if I have a more constructive proposal in terms of more work and less words I will gladly try something.

Thanks again! Andres