[Distutils] distutils.util.get_platform() for Windows

Phillip J. Eby pje at telecommunity.com
Thu Jul 19 03:02:06 CEST 2007


At 10:06 AM 7/19/2007 +1000, Mark Hammond wrote:
> > At 09:13 AM 7/19/2007 +1000, Mark Hammond wrote:
> > >Its not clear from your reply, but do you believe that all
> > architectures
> > >having identical filenames is a problem?  If so, how do you
> > think we should
> > >approach it?
>
>I'm still not sure what the answer to the question is though :)

I just want to make sure that I understand your proposal well enough 
to ensure that 1) it won't cause trouble for eggs and 2) I can 
implement the necessary changes, if any, to setuptools.


> > Mostly, I'm just interested in understanding how to update
> > setuptools' platform API functions:
> >
> > http://peak.telecommunity.com/DevCenter/PkgResources#platform-utilities
>
>That sounds worthwhile - but I'm unsure why we wouldn't simply update
>distutils in similar ways,

Because distutils' get_platform() isn't really clear about the 
distinctions that setuptools makes explicit, about version 
compatibility.  In a sense, distutils' get_platform assumes that no 
platform can run any other platform's code, even though this isn't so 
for at least Mac OS.

For example, if a 'win32' package can be used on 'win64', setuptools 
needs to know this -- but distutils has no clue and doesn't care, 
because distutils doesn't *do* anything with platform information 
except generate filenames (including build directory file names).

Notice that setuptools has *two* different get_*_platform APIs, 
because of this distinction, plus a "compatible_platforms" function; 
distutils doesn't have any of that.

So if we move away from win32 as a platform designator, I need to 
understand *precisely* what values will replace it, so that 
compatible_platforms will be able to support them correctly.

In general, platform strings are an underspecified area of the 
distutils, so if we change anything about them, I'd like to improve 
the specification.  I'm not happy with adding more code whose 
behavior is implementation-defined, as it leaves me with no way to 
figure out what platforms are compatible with what.



More information about the Distutils-SIG mailing list