Ronald Oussoren wrote:
>
> ["fat" binaries on Mac OS X]
>
It's better to make the included architectures explicit and use
this logic for all platforms, not just Mac OS X.
>>>
>>> I would probably have done that, knowing what I know now.
>>>
>>> Hashing out the details on what combinat
> Nate wrote:
> I'd hate to see this only end up in 3. We'll probably be supporting 2.x
> for a long time.
>
> Are we any closer to a plan? =) I just found another: (g)libc version.
Well everyday we get closer to seeing the roadmap..
I can give an official answer on that. See:
http://us.pycon
David Lyon wrote:
On Thu, 14 Jan 2010 10:36:46 +0100, "M.-A. Lemburg" wrote:
Instead, the version string should include the details of
all included builds, ie. 'x86', 'x64', 'ppc', 'ppc64'.
Hashing out the details on what combinations of architectures are valid
during installation will be f
On Thu, 14 Jan 2010 10:36:46 +0100, "M.-A. Lemburg" wrote:
>>> Instead, the version string should include the details of
>>> all included builds, ie. 'x86', 'x64', 'ppc', 'ppc64'.
>> Hashing out the details on what combinations of architectures are valid
>> during installation will be fu
On 14 Jan, 2010, at 10:36, M.-A. Lemburg wrote:
> Ronald Oussoren wrote:
>>
>> On 13 Jan, 2010, at 23:44, M.-A. Lemburg wrote:
>>
>>> Ronald Oussoren wrote:
On 13 Jan, 2010, at 18:41, M.-A. Lemburg wrote:
> Ronald Oussoren wrote:
>>
>> On Wednesday, January 13, 201
Ronald Oussoren wrote:
>
> On 13 Jan, 2010, at 23:44, M.-A. Lemburg wrote:
>
>> Ronald Oussoren wrote:
>>>
>>> On 13 Jan, 2010, at 18:41, M.-A. Lemburg wrote:
>>>
Ronald Oussoren wrote:
>
> On Wednesday, January 13, 2010, at 04:15PM, "M.-A. Lemburg"
> wrote:
>
>>
>>
On 13 Jan, 2010, at 23:44, M.-A. Lemburg wrote:
> Ronald Oussoren wrote:
>>
>> On 13 Jan, 2010, at 18:41, M.-A. Lemburg wrote:
>>
>>> Ronald Oussoren wrote:
On Wednesday, January 13, 2010, at 04:15PM, "M.-A. Lemburg"
wrote:
>
>> 2) On OS X, the modification to t
Ronald Oussoren wrote:
>
> On 13 Jan, 2010, at 18:41, M.-A. Lemburg wrote:
>
>> Ronald Oussoren wrote:
>>>
>>> On Wednesday, January 13, 2010, at 04:15PM, "M.-A. Lemburg"
>>> wrote:
>>>
> 2) On OS X, the modification to the value returned by
> pkg_resources.get_platform() isn't cor
On 13 Jan, 2010, at 18:41, M.-A. Lemburg wrote:
> Ronald Oussoren wrote:
>>
>> On Wednesday, January 13, 2010, at 04:15PM, "M.-A. Lemburg"
>> wrote:
>>
>>>
2) On OS X, the modification to the value returned by
pkg_resources.get_platform() isn't correct for fat version of Python
>>>
On Wednesday, January 13, 2010, at 04:15PM, "M.-A. Lemburg"
wrote:
>
>> 2) On OS X, the modification to the value returned by
>> pkg_resources.get_platform() isn't correct for fat version of Python
>> 2.5, as detailed in setuptools issue 19. To solve that, we're using the
>> patch I submitted
Ronald Oussoren wrote:
>
> On Wednesday, January 13, 2010, at 04:15PM, "M.-A. Lemburg"
> wrote:
>
>>
>>> 2) On OS X, the modification to the value returned by
>>> pkg_resources.get_platform() isn't correct for fat version of Python
>>> 2.5, as detailed in setuptools issue 19. To solve that, w
Nate Coraor wrote:
> Hi,
>
> I'm involved with a software project that makes extensive use of third
> party modules with C extensions. To ease installation, we pre-build
> them for some popular platforms and provide a distribution system for
> the app to fetch them.
>
> setuptools uses distutils
On Wed, Jan 13, 2010 at 5:47 PM, Tarek Ziadé wrote:
> Because at the end, If i understand the need correctly, it will be
> used where get_platform()
> is used today
I don't think that's true - get_platform only returns the platform. It
has been used for ABI check by accident, and if you look at
On Wed, Jan 13, 2010 at 7:17 AM, David Cournapeau wrote:
> On Wed, Jan 13, 2010 at 10:18 AM, Tarek Ziadé wrote:
>
>>
>> Besides a well-defined ABI, if usc2/usc4 + 32/64 bits distinction on
>> some platforms
>> already fixes a numbers of use cases, I think could worth it for 2.7/3.2
>
> What bothe
David Cournapeau wrote:
If a function to qualify an ABI on a specific platform is needed, it
should be a new function IMHO.
+1, but I do think that this new function should provide the level of
detail that Nate is asking for.
cheers,
Chris
--
Simplistix - Content Management, Batch Processi
On Wed, Jan 13, 2010 at 10:18 AM, Tarek Ziadé wrote:
>
> Besides a well-defined ABI, if usc2/usc4 + 32/64 bits distinction on
> some platforms
> already fixes a numbers of use cases, I think could worth it for 2.7/3.2
What bothers me is that get_platform is the wrong function for this -
it is al
Nate wrote:
> It's not even crucial to me that these be fixed, but before I continue
> to hack up the platform string, I wanted to ask the SIG to address these
> issues and hopefully decide on a standard. That way, I can at least
> implement patches in my app that will be compatible with whatever
Tarek Ziadé wrote:
It's not even crucial to me that these be fixed, but before I continue to
hack up the platform string, I wanted to ask the SIG to address these issues
and hopefully decide on a standard. That way, I can at least implement
patches in my app that will be compatible with whateve
On Wed, Jan 13, 2010 at 2:01 AM, David Cournapeau wrote:
> On Wed, Jan 13, 2010 at 3:08 AM, Nate Coraor wrote:
>
>>
>> It's not even crucial to me that these be fixed, but before I continue to
>> hack up the platform string, I wanted to ask the SIG to address these issues
>> and hopefully decide
On Wed, Jan 13, 2010 at 3:08 AM, Nate Coraor wrote:
>
> It's not even crucial to me that these be fixed, but before I continue to
> hack up the platform string, I wanted to ask the SIG to address these issues
> and hopefully decide on a standard. That way, I can at least implement
> patches in m
Hi Tarek,
i386 wrote:
>> setuptools uses distutils.util.get_platform() to decide whether an egg
>> found .. Unfortunately, get_platform() .. compatibility.
>
> I think that this has to be discussed at Distutils/stdlib level.
> Notice that I am currently in the
> process of moving get_platform()
On Tue, Jan 12, 2010 at 7:08 PM, Nate Coraor wrote:
> Hi,
>
> I'm involved with a software project that makes extensive use of third party
> modules with C extensions. To ease installation, we pre-build them for some
> popular platforms and provide a distribution system for the app to fetch
> the
> Hi,
>
> I'm involved with a software project that makes extensive use of third
> party modules with C extensions...
>
> setuptools uses distutils.util.get_platform() to ...
> ..
> ..
> It's not even crucial to me that these be fixed, but before I continue
> to hack up the platform string, I wante
Hi,
I'm involved with a software project that makes extensive use of third
party modules with C extensions. To ease installation, we pre-build
them for some popular platforms and provide a distribution system for
the app to fetch them.
setuptools uses distutils.util.get_platform() to decide
24 matches
Mail list logo
