stdeb
stdeb copied to clipboard
astraw
generate debian/watch file
This pull request adds support for generating debian/watch file (which uses http://pypi.debian.net redirector to track new upstream releases)
I'm using stdeb for an application that depends on pyqt4/5. There is no point in uploading to pypi because those dependencies are not available. Afaik python bindings for gtk3 aint available as well, only the older pygtk bindings. I'd say having a graphical python application not on pypi is not uncommon.
What do you think about using pypi.debian.net as default line for the watch file that can be overridden by stdeb cfg for those packages that are not on pypi? I'd prepare a PR if you'd think this is the way to go
Also related to the watchfile would be a stdeb cfg option to provide upstreams signing key. Signing is supported by pypi and with debians redirector as well. Maybe amend the pypi.debian.net default with pgpsigurlmangle if a signing key gets provided by stdeb config (and no explicit watch line)?
I don't really understand why --watch path/to/my/watch is better than cp path/to/my/watch debian/
I was thinking of something like:
watch = http://somesite.com/dir foo/program-(.+)\.tar\.gz
that can be provided on the command line or in the cfg-file
having the watchfile autogenerated is perfect if the package is on pypi, but being on pypi is not that common for graphical applications since some dependencies are missing. thats why I thought a stdeb param is useful to document the watchfile generation somehow, instead of surprising the user with lintian warnings later on. a boolean autogenerate watchfile param that defaults to true would serve the same purpose but being able to pass a different line for the watchfile would be more flexible
not quite sure if this is needed/wanted, thats why I was asking instead of preparing a PR that would show the intention more clearly but might be a waste of time
For a package which might not be released to PyPI it would be good if this file wasn't generated unconditionally. For backward compatibility opt-in would be preferred but I can see why opt-out would be nice to have.
