Seiler, Thank you for your reply.
According to [1], the author of uritemplate-2 replied the question "What do you think of giving the project another name? "uritemplate" is a too generic." No. "uritemplate" and "uritemplate.py" were created around the same time > and each had the same number of apparent downloads. Both were in use, and > we've consolidated on "uritemplate". We're going to keep that and we're > doing *no more* renames. > These two utilities are similar but independent and API incompatible, I will try to create a new package. I had tried to contact current maintainers of python-uritemplate two weeks ago but got no response yet. ref: [1]: https://github.com/sigmavirus24/uritemplate/issues/27 -- Sun-Ze Lin (林上智) 2016-10-16 16:36 GMT+08:00 Christian Seiler <christ...@iwakd.de>: > On 10/16/2016 10:07 AM, Alec Leamas wrote: > > On 16/10/16 09:35, SZ Lin (林上智) wrote: > >> I want to package python library - *uritemplate* [1]; however, I found > >> that there is a same name package with similar function in Debian > >> archive [3]. > > > >> Do you have any suggestion on it ? > > > > What about following the github scheme i. e., > > sigmavirus24-python-urltemplate? Certainly not elegant, but at least > > adhering to the "follow the upstream" principle. > > You'd still need to add Conflicts: python-uritemplate to the package, > (because of the same Python package name) but that would make the new > package not coinstallable with the following rdepends: > > apt-cache rdepends python-uritemplate > python-uritemplate > Reverse Depends: > python-googleapi > slapos-client > python-oauth2client > > But that doesn't necessarily mean that this problem can't be resolved > differently. > > For the sake of clarity in the discussion, let's call the package in > Debian uritemplate-1 (see [1]) and the package not (yet) in Debian > uritemplate-2 (see [2]). > > If you look at <https://github.com/uri-templates/uritemplate-py/>, > it says that you can install uritemplates-1 via > > pip install uritemplate > > But if you look at the current PyPI metadata, you see that the current > PyPI package referes to uritemplate-2. Also consider the fact that if > you look at the git repository of uritemplate-1, the last commit is > from Dec. 2015, while uritemplate-2 has commits from this year. > > To me, this looks very much like that there were initially two packages > with the same name that did very similar things. And that in August of > this year uritemplate-1 was discontinued in favor of uritemplate-2, > with some features that were initially not in uritemplate-2 merged > from uritemplate-1. > > @林上智: When you asked uritemplate-2 upstream about the naming thing, > you only referenced the PyPI packages in the github issue, and not the > actual repository of uritempalte-1 [1]. It would be great if you could > ask them for clarification again and see if my analysis (the previous > paragraph in this email) is correct and that uritemplate-1 is really > discontinued. Also maybe ask about API compatibility between the old > and new packages. > > Because if it is correct, the proper way forward would be to not > package uritemplate-2 separately in Debian, but (assuming there's API > compatibility in the sense that current rdeps in Debian work, you'd > have to test that) to simply alter the current package in Debian to > use uritemplate-2 as it's new upstream source and update that package. > After confirming with upstream, you should contact the current > Maintainers of python-uritemplate, see [3]. > > Regards, > Christian > > [1] https://github.com/uri-templates/uritemplate-py/ > [2] https://github.com/sigmavirus24/uritemplate > [3] https://tracker.debian.org/pkg/python-uritemplate > >
