On 10/07/2015 01:04, Marko Rauhamaa wrote:
Chris Angelico :
Your descriptions conflict. A safe binary replacement usually cannot
even add new features, in case this breaks something.
New functions in C libraries do not cause runtime breakage.
It's good to know that there's never been a cra
Chris Angelico :
> Your descriptions conflict. A safe binary replacement usually cannot
> even add new features, in case this breaks something.
Linus Torvalds is adamant about maintaining ABI compatibility across
Linux versions. That hasn't prevented him from accepting numerous new
system calls.
On Fri, Jul 10, 2015 at 7:33 AM, Marko Rauhamaa wrote:
>> And just how compatible does it have to be to get a tick?
>
> It must be a safe binary replacement of the earlier version. Bug fixes
> and new features are ok, but none of the old functionality can be
> obsoleted.
Your descriptions conflic
Chris Angelico :
> On Fri, Jul 10, 2015 at 7:11 AM, Marko Rauhamaa wrote:
>> Whoever creates B-1.1 ought to make it backward-compatible, but he
>> should also say so. The majority of developers are careless about
>> backward-compatibility; having the component system make wishful
>> assumptions wi
On Fri, Jul 10, 2015 at 7:11 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> In general, I would expect that B 1.1 is backward-compatible with B
>> 1.0, unless otherwise stated. Why must it be declared in any way other
>> than the version number?
>
> To make it explicit. The generic component sy
Chris Angelico :
> In general, I would expect that B 1.1 is backward-compatible with B
> 1.0, unless otherwise stated. Why must it be declared in any way other
> than the version number?
To make it explicit. The generic component system shouldn't impose
(m)any assumptions on version numbering. Ve
On Fri, Jul 10, 2015 at 6:36 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> How do you expect the end result to work? Will it be that your code
>> imports one version of a module, but other code imports another? You
>> would have to rename one of them or something.
>
> At work, we have created
Chris Angelico :
> How do you expect the end result to work? Will it be that your code
> imports one version of a module, but other code imports another? You
> would have to rename one of them or something.
At work, we have created an analogous component system that has solved
this issue the way
On Fri, Jul 10, 2015 at 5:55 AM, Cyril Scetbon wrote:
> It's just a sample. I'd like to get a general answer. So think about the
> worst case.
(Please don't top-post on this list.)
The worst case is virtually impossible to handle. Somewhere along the
way, you need to say "import B" and Python h
It's just a sample. I'd like to get a general answer. So think about the worst
case.
> On Jul 9, 2015, at 21:50, Chris Angelico wrote:
>
> On Fri, Jul 10, 2015 at 5:08 AM, Cyril Scetbon wrote:
>> Forcing my-module to use B=1.1 fixes the issue. However it's just a sample
>> and my code is using
On Fri, Jul 10, 2015 at 5:08 AM, Cyril Scetbon wrote:
> Forcing my-module to use B=1.1 fixes the issue. However it's just a sample
> and my code is using a lot of modules that use other shared modules too. Is
> there a way to let dependencies use their own version of the modules they
> need whi
Hi,
I use pip to install modules and setuptools to install dependencies, and
generate a console_script using the entry_point parameter of setup.
Here is the issue :
my current sources depend on modules, let's say A=1.0, B=1.0, C=2.0. And C
depends on B=1.1
I have no problem with using pip to in
12 matches
Mail list logo
