[Distutils] Platform naming standardization

[Nate Coraor]

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
>> settings).
> 
> 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
> millenia.
> 
> 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.

--nate

> David
> 
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig