[Distutils] Platform naming standardization
nate at psu.edu
Mon Jan 18 13:43:53 CET 2010
David Lyon wrote:
> On Thu, 14 Jan 2010 10:36:46 +0100, "M.-A. Lemburg" <mal at egenix.com> 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 fun though ;-). That is, if my python says
>>> its machine is "i386,x86_64" is it then acceptable to install an "i386"
>>> binary, an "i386,x86_64" binary, and "i386,ppc, x86_64" binary?
>> The point is that even though your Python binary may say it's
>> "i386,x86_64", the version you run your application with
>> will either be "i386" or "x86_64" (depending on the OS environment
> That's right.
>> Now let's say you're running the "i386" version. As long as all
>> installed components provide the "i386" part you should be fine.
>> In your example all components provide the "i386" part, so all
>> of them can be installed.
> The main point here though is being able to trigger the correct
> build for non-standard configuration, no matter what the
> platform. We're having the same issue on Windows as it
> is running the same processors.
>> In a few years, we'll probably only see "x86_64" binaries for
>> Mac OS, but until then, package installers will have to
>> be able to work out the problem of finding installable
>> distribution files among the available ones.
> We'll see what if anything gets changed/fixed.
> I'm concerned about the excessive use of code-freeze-spray
> being used in 2010. That's where you take 5-10 year old
> code and just freeze it into place.
> I'd really like to see distutils create packages and run
> in a browser window. That's my wish to santa.
> Having a 64-bit processor and a 10 year old command line
> interface on distutils, seems somewhat wrong in this
> There really is so much to do.. we could make a really
> fresh start with Python 3 and make it really different
> and better than Python 2.x
> I'd love to see a plan or a roadmap for packaging for 2010..
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.
> Distutils-SIG maillist - Distutils-SIG at python.org
More information about the Distutils-SIG