My solution is patch the upstream with "sys.path.insert" function.
I wonder that is there a more elegant solution to achieve this goal but
without upstream patch ?
--
Sun-Ze Lin (林上智)
2016-10-18 19:51 GMT+08:00 Ian Jackson :
> Lars Wirzenius writes ("Re: Package name
Lars Wirzenius writes ("Re: Package name conflict question"):
> I don't have a solution for this. The ideal solution would be for one
> or both upstream developers to rename their library. However, that's
> only ideal in the long run, since it requires every program th
On 2016-10-18 9:52, SZ Lin wrote:
I think this situation meets the condition.
The case of two programs having the same functionality but different
implementations is handled via "alternatives" or the "Conflicts"
mechanism.
These two programs having the same functionality - implementation of
R
Hi Ansgar,
Thanks for your reply.
I think this situation meets the condition.
The case of two programs having the same functionality but different
> implementations is handled via "alternatives" or the "Conflicts" mechanism.
These two programs having the same functionality - implementation of
"SZ Lin (林上智)" writes:
> Although these packages are not API-compatible, they are using the
> same installation path and file name; therefore, I think "Conflict:"
> section is needed.
Note that Policy explicitly forbids using "Conflicts" in this case, see
the first paragraph in [1].
[1]
On Tue, Oct 18, 2016 at 03:36:56PM +0800, SZ Lin (林上智) wrote:
> Although these packages are not API-compatible, they are using the
> same installation path and file name; therefore, I think "Conflict:"
> section is needed.
The problem with this is that this prevents our users from having both
of t
Hi Adam,
Thanks for your reply.
Although these packages are not API-compatible, they are using the
same installation path and file name; therefore, I think "Conflict:"
section is needed.
--
Sun-Ze Lin (林上智)
2016-10-17 2:27 GMT+08:00 Adam Borowski :
> On Sun, Oct 16, 2016 at 10:36:31AM +0200
Hi Alec,
Thank you for your reply.
This name seems suitable for the new package.
--
Sun-Ze Lin (林上智)
2016-10-16 16:21 GMT+08:00 Alec Leamas :
>
>
> On 16/10/16 10:07, Alec Leamas wrote:
>
>>
>>
>> On 16/10/16 09:35, SZ Lin (林上智) wrote:
>>
>>> Hi,
>>>
>>> I want to package python library - *
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
On Sun, Oct 16, 2016 at 10:36:31AM +0200, Christian Seiler wrote:
> 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 Debi
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 abou
On 16/10/16 10:07, Alec Leamas wrote:
On 16/10/16 09:35, SZ Lin (林上智) wrote:
Hi,
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 followin
On 16/10/16 09:35, SZ Lin (林上智) wrote:
Hi,
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-
Hi,
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].
Despite these function are similar, the API seems like incompatible in each
other. The reason why I want to package [1] is that because there
14 matches
Mail list logo