rpm-software-management / tito

A tool for managing rpm based git projects.
GNU General Public License v2.0
378 stars 129 forks source link

Support for programming language package managers #237

Open msehnout opened 7 years ago

msehnout commented 7 years ago

It would be nice, if tito could cooperate with a package manager specific to a certain programming language.

For example these package managers: Cargo, OPAM, Cabal have their own configuration file with a line specifying the version of the package. tito tag could either read the version from the file or write to the file.

Current solution: Using the template_file option, I can create something like this: tito.props:

[version_template]
destination_file = Cargo.toml
template_file = Cargo.toml.template

Template:

[package]
name = "hello_tito"
version = "$version"
authors = ["xxx"]

[dependencies]

Result:

[package]
name = "hello_tito"
version = "0.1.1"
authors = ["xxx"]

[dependencies]

But this is somewhat annoying when I want to change the Cargo.toml file without making new tag.

Proposed solution: tito.props

[version_file]
pkg_type = cargo
config_file = Cargo.toml

What do you think? Is it a desirable feature in tito?

dgoodwin commented 7 years ago

There's some precedent here, tito will automatically update a setup.py version if one exists. However I'm not totally clear on why the template mechanism doesn't suffice.

Tito is made to build specific tags (including past tags) and exports the source for that tag during the build, which would not include uncommitted or untagged changes. (which is good for reproducible builds)

So I would expect that you would tag a change to your config.toml and rebuild, perhaps using a "release" tagger though if it's purely a packaging change similar to what you would do with rpm spec changes only, i.e. 0.0.1-1 becomes 0.0.1-2 instead of 0.0.2-1.

I don't use the templating though so feel free to elaborate on anything I might be missing.

msehnout commented 7 years ago

The problem I'm thinking of would be like this: You make a tag, then you continue developing the package and meanwhile change dependencies etc. in Cargo.toml. When you are ready to release new version, you have to recreate the template again to contain the same as the current Cargo.toml.

In this case, it would probably be better not to use the template at all and just bump the version in Cargo.toml by hand.

My idea is to use tito tag and bump version in both spec file and Cargo.toml.

dgoodwin commented 7 years ago

Hmm I think I understand yes, that sounds exactly like what we do for setup.py. I would be open to a PR adding that functionality.

msehnout commented 7 years ago

ok, I'll take a look at it.

dgoodwin commented 7 years ago

Here is the relevant setup.py example: https://github.com/dgoodwin/tito/blob/master/src/tito/tagger/main.py#L135

Might be good to think about how to organize if this list of supported files starts to grow, or how to let users control which ones are enabled or disabled, I think setup.py is assumed if we see one, we try to update it. Not sure if that is a good path forward or not.

There are tests that should be easy to build on as well.

msehnout commented 7 years ago

I made a concept of this feature and it looks like this:

Usage in tito.props:

[remote_pkg_manager]
type = cargo
config_file = Cargo.toml

How it works in the code:

  1. New step in _tag_release method. Here I read the config file and decide what tagger to use: https://github.com/msehnout/tito/blob/cargo/src/tito/tagger/main.py#L143
  2. New file with the tagger class for Cargo (adding other pkg managers would require similar class): https://github.com/msehnout/tito/blob/cargo/src/tito/tagger/cargotagger.py
  3. Finally tests for this class: https://github.com/msehnout/tito/blob/cargo/test/unit/common_tests.py#L265

Any comments? Shall I just create a PR so you can easily comment on the code?

dgoodwin commented 7 years ago

PR would be very helpful, I will take a look once it's up, thanks.