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

No. "uritemplate" and "" 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.


Sun-Ze Lin  (林上智)

2016-10-16 16:36 GMT+08:00 Christian Seiler <>:

> 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 <>,
> 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]
> [2]
> [3]

Reply via email to