[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Package name conflict question



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.


2016-10-16 16:36 GMT+08:00 Christian Seiler <christian@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



Reply to: