[Distutils] An idea on the creation of binary installers
Suchandra Thapa
s-thapa-11@alumni.uchicago.edu
Sun Feb 23 22:54:01 2003
--=-kIhZCjsUQ/MlKsk6kSBa
Content-Type: multipart/alternative; boundary="=-xvUTo08VYonJbRjXJcsF"
--=-xvUTo08VYonJbRjXJcsF
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Sun, 2003-02-23 at 16:31, Jack Jansen wrote:
The bdist_dumb formats have exactly that problem: they're too dumb.=20
They basically create a tarfile (or other archive type) with full=20
pathnames in it and that's it. However, there could be a bdist_xxx=20
which would create a tarfile in which everything was relative, but the=20
directory parts are magic. If you extract this tarfile with a normal=20
tar you would get a directory with under it directories INSTALL_BASE,=20
INSTALL_PLATBASE, ROOT, etc etc etc. Or maybe all these would be rooted=
=20
in a xxx/platform.machine.version directory, probably a better idea.=20
The tar file would also contain the setup.py script.
I think the problem is not so much in distributing binaries as
generating the binaries and matching them to the user's system. This
isn't a problem with pure python modules but it is a significant problem
with non pure modules. For example, wxPython requires the wxWindows
libraries and due to various issues you can't really create a generic
wxPython binary and expect it to work on all versions of a given os. If
you try to provide binaries for different versions of a binary, you'll
quickly end up with a huge number of environments that you need to
support. For linux systems alone, you'll need to support redhat
7.x,redhat 8.x, debian 3.0, and one or two versions of mandrake just to
support some of the most popular distributions. Add in the *BSD
systems, solaris, and windows and you have a huge task ahead of you.
The best option at the moment would probably be to go with the
traditional source install and compile on unix based systems along with
something like bdist_dumb (but with a little more intelligence) and a
binary install for windows. The bdist_dumb option would provide a basic
binary install but should be something that requires some conscious
decision so that the user realizes that the binary install will probably
not work unless the user's system matches the system the module was
compiled on. =20
--=20
------------------------------------------------------------------
Suchandra S. Thapa=20
s-thapa-11@alumni.uchicago.edu
------------------------------------------------------------------
--=-xvUTo08VYonJbRjXJcsF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; CHARSET=3DUTF-8">
<META NAME=3D"GENERATOR" CONTENT=3D"GtkHTML/1.0.2">
</HEAD>
<BODY>
On Sun, 2003-02-23 at 16:31, Jack Jansen wrote:
<BR>
<FONT SIZE=3D"3"></FONT>
<BLOCKQUOTE>
<PRE><FONT COLOR=3D"#737373"><FONT SIZE=3D"3"><I>The bdist_dumb formats hav=
e exactly that problem: they're too dumb. </FONT></FONT></I>
<FONT COLOR=3D"#737373"><FONT SIZE=3D"3"><I>They basically create a tarfile=
(or other archive type) with full </FONT></FONT></I>
<FONT COLOR=3D"#737373"><FONT SIZE=3D"3"><I>pathnames in it and that's it. =
However, there could be a bdist_xxx </FONT></FONT></I>
<FONT COLOR=3D"#737373"><FONT SIZE=3D"3"><I>which would create a tarfile in=
which everything was relative, but the </FONT></FONT></I>
<FONT COLOR=3D"#737373"><FONT SIZE=3D"3"><I>directory parts are magic. If y=
ou extract this tarfile with a normal </FONT></FONT></I>
<FONT COLOR=3D"#737373"><FONT SIZE=3D"3"><I>tar you would get a directory w=
ith under it directories INSTALL_BASE, </FONT></FONT></I>
<FONT COLOR=3D"#737373"><FONT SIZE=3D"3"><I>INSTALL_PLATBASE, ROOT, etc etc=
etc. Or maybe all these would be rooted </FONT></FONT></I>
<FONT COLOR=3D"#737373"><FONT SIZE=3D"3"><I>in a xxx/platform.machine.versi=
on directory, probably a better idea. </FONT></FONT></I>
<FONT COLOR=3D"#737373"><FONT SIZE=3D"3"><I>The tar file would also contain=
the setup.py script.</FONT></FONT></I></PRE>
</BLOCKQUOTE>
<FONT SIZE=3D"3"></FONT>
<BR>
<FONT SIZE=3D"3">I think the problem is not so much in distributing binarie=
s as generating the binaries and matching them to the user's system. =
This isn't a problem with pure python modules but it is a significant probl=
em with non pure modules. For example, wxPython requires the wxWindow=
s libraries and due to various issues you can't really create a generic wxP=
ython binary and expect it to work on all versions of a given os. If =
you try to provide binaries for different versions of a binary, you'll quic=
kly end up with a huge number of environments that you need to support.&nbs=
p; For linux systems alone, you'll need to support redhat 7.x,redhat 8.x, d=
ebian 3.0, and one or two versions of mandrake just to support some of the =
most popular distributions. Add in the *BSD systems, solaris, and win=
dows and you have a huge task ahead of you.</FONT>
<BR>
<FONT SIZE=3D"3"></FONT>
<BR>
<FONT SIZE=3D"3">The best option at the moment would probably be to go with=
the traditional source install and compile on unix based systems along wit=
h something like bdist_dumb (but with a little more intelligence) and a bin=
ary install for windows. The bdist_dumb option would provide a basic binary=
install but should be something that requires some conscious decision so t=
hat the user realizes that the binary install will probably not work unless=
the user's system matches the system the module was compiled on. </F=
ONT>
<BR>
<FONT SIZE=3D"3"></FONT>
<TABLE CELLSPACING=3D"0" CELLPADDING=3D"0" WIDTH=3D"100%">
<TR>
<TD>
<PRE>--=20
------------------------------------------------------------------
Suchandra S. Thapa=20
s-thapa-11@alumni.uchicago.edu
------------------------------------------------------------------</PRE>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>
--=-xvUTo08VYonJbRjXJcsF--
--=-kIhZCjsUQ/MlKsk6kSBa
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEABECAAYFAj5ZlysACgkQ6nShCjt5AZLnrwCgkLd7obKFJ/ErT3Pn9zMT7Yfq
a3AAni2SUYN5DtPieckHEI6BMYSPMdG3
=jZ8M
-----END PGP SIGNATURE-----
--=-kIhZCjsUQ/MlKsk6kSBa--