[Python-Dev] The other Py2.4 issue
p.f.moore at gmail.com
Sun Dec 12 18:26:49 CET 2004
On Sat, 11 Dec 2004 19:57:55 +0100, Christian Tismer
<tismer at stackless.com> wrote:
> Armin Rigo wrote:
> > Hum, this is getting into a Linux-vs-Windows argument. I don't want to invest
> > time and money on Windows tools just to compile my extension module for
> > Windows users...
First of all, I'm assuming this is a timing issue. If I understood
your initial posting, your concern was that people wanted Windows
build of your extension *now*, and it was going to take you time to
make it available.
That's a different issue from you not having the facilities to build
the Windows installers at all, where you rely on 3rd parties making
As Martin points out, ultimately the provision of Windows binaries is
an issue for the extension project - is the demand high enough to
justify the effort, can you find tools and/or a helper, etc etc.
But the former issue (how quickly you can provide binaries, assuming
that you will do so ultimately) is more relevant for python-dev.
Specifically, because lack of binary extensions can be a barrier to
take-up of the new version. Certainly, in the past, you could pretty
much guarantee that there would be very few Windows users testing beta
releases, because pywin32 binaries weren't available. With 2.4, I have
at least one system I'd upgrade *now* but for the lack of a critical
extension in binary form (I haven't yet had the time to try to adapt
the build process to mingw for myself).
> Maybe we can set this up as a service?
That sounds like a good idea. What I'd suggest is needed is a website
where the following can take place:
1. People have a way of posting rquests for particular modules.
2. Installers can be uploaded to satisfy those requests.
3. There is somewhere to put step-by-step "build it yourself"
instructions, using free components, so that people *without* access
to VS.NET can make progress themselves. Obviously, if a particular
extension can't be built with free compilers, then binaries or access
to VS.NET are the only options.
The installers should be clearly noted as having no warranty or
support implied, to encourage people to offer binaries they have built
without feeling that they are taking on a support burden. Conversely,
as soon as "official" binaries are available from the extension
project, the binaries available here should be removed (and replaced
with a link to the official site) to reinforce the "unofficial" nature
of the binaries provided here.
The biggest potential issue with such a site is clearly validation.
I've no idea how to make something like this work without it being a
major virus risk. Which may, sadly, be enough to kill the idea :-(
More information about the Python-Dev