David Lyon wrote:
On Thu, 14 Jan 2010 10:36:46 +0100, "M.-A. Lemburg" <[email protected]> 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  -  [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________
Distutils-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig

Reply via email to