proposed feature: diff option

[marbu]

I propose to add --diff option which would read already existing specfile in current directory, check which options were chosen (eg. base python or distro), generate new default specfile using detected options and based on that, show diff of these two specfiles.

So for example when I have python-projectname.spec in current directory, running pyp2rpm --diff -n projectname would show me just differences my specfile contains compared to default generated one.

This feature is modelled on diff subcommand of cabal-rpm tool and it would be usefull for checking specfile during review.

[marbu]

I'm trying to check feedback before/instead of writing the code. It's likely that my idea would need some tweaks to better fit into fedora packaging culture.

[mcyprian]

I am not sure if this would be so useful. Metadata extraction is limited and generated spec file usually needs to be corrected. For example I tried to make diff of current version of python-nose in fedora and spec file created by pyp2rpm, this was a result: https://paste.fedoraproject.org/315790/14539935/ So we might consider if diff is the right solution for this purpose. If you want to implement this option, and you find the way how to make it useful, we will of course accept it.

[bkabrda]

I'd say that this feature might actually be very useful - two examples come to my mind right now:

• When a new version of package is released, the dependencies (and their required versions) may change. Instead of going through dependencies in specfile and new release one by one (usually a very tedious process), user could just run the diff and see what's changed.
• Sometimes Fedora (Python) Packaging guidelines change and I don't even notice. Assuming that pyp2rpm follows the best practices, I can run it and see if something has changed in the recommended/required approach of packaging Python extensions.

Even though the generated specfile (usually) needs corrections, it would still make sense to be able to see the diff, IMO.

[marbu]

Thanks for the feedback. @mcyprian is right that for a specfile that hasn't been generated by pyp2rpm tool and contains a lot of additional tweaks, the diff feature is not that useful. That said, there are some other cases when it would make sense, as @bkabrda points out. The use case I had in mind when thinking about the diff feature was this: a maintainer creates an rpm package using pyp2rpm tool and somebody else would like to check out what changes the maintainer has done compared to pyp2rpm defaults (eg. during a fedora package review). Anyway, I'm going to write 1st implementation of this feature and add some expected uses cases to make this clear.

[hroncok]

Another use case I can think would be to generate a diff not between a given spec and a spec generated by pyp2rpm, but between 2 specs generated by pyp2rpm.

Consider the following scenario:

1. A package maintainer runs pyp2rpm on foo, current version is 0.1
2. The maintainer changes a spec to fit his/her needs.
3. After a while, foo 0.2 is released, the maintainer withes to update python-foo.spec
4. The maintainer runs some command (such as pyp2rpm --diff python-foo.spec)
5. pyp2rpm finds out the version from the spec, runs the procedure for 0.1 and 0.2 and creates a diff
6. This diff might be applied to the spec to update it to 0.2

If we get things more clever (such as dealing with %changelog), we might be able to automate this procedure to a way that the maintainer could just run something like pyp2rpm --update python-foo.spec.

[bkabrda]

If we get things more clever (such as dealing with %changelog), we might be able to automate this procedure to a way that the maintainer could just run something like pyp2rpm --update python-foo.spec.

Huge +1, this would be awesome.

[mcyprian]

This tool https://github.com/phracek/rebase-helper helps to rebase spec file to the latest version, it contains support of python spec files. Modules for parsing data from current spec file etc. are included there. if we make a decision to implement --update option, it might be possible to reuse some of the rebase-helper's modules.

[jwmullally]

The diff/git diff or the rebase tools seem like a more reusable and lower maintenance approach for general purpose spec diffing, it doesn't make sense to duplicate them in every spec generator tool. IMHO the generator tools should only cover the domain specific problem of package -> spec/SRPM.

which would read already existing specfile in current directory, check which options were chosen (eg. base python or distro), generate new default specfile using detected options and based on that, show diff of these two specfiles.

A simple approach could be to write the pyp2rpm command line to the generated spec file in a comment, which could later be easily grep'd by the next person/tool to do the updating.

It should be all that is needed as the output spec is a function of only:

• the input CLI arguments (for python version, pkg name etc)
• the package
• pyp2rpm

and the CLI args are the only user-controllable part of the auto-generation anyway.

[mcyprian]

rebase-helper should now support similar use case https://github.com/rebase-helper/rebase-helper/pull/289.