I don't claim that I read everything that all of you posted on the topic of retrieving and storing the configuration information from the Python build process - I also have to work in between ;-) But it seems to me that this discussion misses the point, or at least deals with a minor implementation detail. The build phase of the installation process (needed only for source installation of extension modules, of course) should use a much higher-level interface to the DistUtil core than just the information from the Makefile. As a package provider, I want to write something like from DistUtils import compileExtensionModule compileExtensionModule("foo", ["foomodule.c", "bar.c"]) Everything lower-level is an implementation detail and not worth 10 KB of discussion ;-) A DistUtils implementation for Python 1.5.x on Unix will have to parse the configuration file or Makefile from the Python build, using some module much like the one posted by Fred. For other platforms, this kind of information may not be available, or not necessary, or useless. For later Python versions, everything might be different. So I see no reason at all to store such specific data in a documented standard library module, whatever it is called. It may even be better not to store it at all and parse the original input every time the information is needed. And now for something completely different: implementation strategy. At some point we will have to move from discussing to programming, after all. It seems to me that the whole DistUtils project divides nicely into two almost independent subunits: - building binaries from source code - installing Python modules and binary extension modules So maybe we should create two "task forces" that work on these subtopics, of course communicating as necessary. That said, I'll disappear for a two-week Christmas vacation, hoping that the discussion during these two weeks won't fill up all my disk space... Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------
Konrad Hinsen writes:
The build phase of the installation process (needed only for source installation of extension modules, of course) should use a much higher-level interface to the DistUtil core than just the information
I agree; I think the expectation is a slightly higher level interface than that: you provide something declarative, telling the distutils package what your inputs are and what sort of module you want to build. And it does the rest.
Everything lower-level is an implementation detail and not worth 10 KB of discussion ;-)
Probably not, if someone gets to go off and do the whole thing. I think we're trying to share the load, though. And we just like email. ;-)
I see no reason at all to store such specific data in a documented standard library module, whatever it is called. It may even be better not to store it at all and parse the original input every time the information is needed.
I'm fine with this. It can just be distutils.sysconfig, have a comment saying it's just an implementation detail, and ...
after all. It seems to me that the whole DistUtils project divides nicely into two almost independent subunits:
- building binaries from source code
- installing Python modules and binary extension modules
Good breakdown. Each of these needs to consider at least three platforms for the initial release: Unix, Windows, and Mac.
That said, I'll disappear for a two-week Christmas vacation, hoping that the discussion during these two weeks won't fill up all my disk
Hah! Never leave your email unattended.... ;-) -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191
Quoth Konrad Hinsen, on 18 December 1998:
Everything lower-level is an implementation detail and not worth 10 KB of discussion ;-)
True to a certain extent -- but hey, we're programmers; we can't help indulge in talking about low-level implementation details even when we don't really have a high-level design. But you're right that this *is* a detail and should take a backseat to design matters for the time being, although I think the discussion on sysconfig has been very useful and productive.
And now for something completely different: implementation strategy. At some point we will have to move from discussing to programming, after all. It seems to me that the whole DistUtils project divides nicely into two almost independent subunits:
- building binaries from source code
- installing Python modules and binary extension modules
I know you (and most of the people who've been active on the SIG, for that matter) weren't there, but we covered this pretty well at the Developer's Day session. The split is subtly different, into three roles: * developer - builds from source tree, creates source distribution, possibly creates built distribution(s) * packager - builds from source distribution, creates built distribution(s) * installer - one of: - builds from source distribution, installs - installs from built distribution See the session summary at http://www.foretec.com/python/workshops/1998-11/dd-ward-sum.html for details. If you don't want to read the whole bloody thing, scroll down to the big "workflow" diagram. This really illustrates a lot of what you're talking about, and what needs to be automated by the distutils.
So maybe we should create two "task forces" that work on these subtopics, of course communicating as necessary.
Not a bad idea, but it would be *three* task forces: for building, for creating distributions (source or built; built distributions can further be smart or dumb), and for installing. Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 x287 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913
On Fri, 18 Dec 1998, Konrad Hinsen wrote:
It seems to me that the whole DistUtils project divides nicely into two almost independent subunits:
- building binaries from source code
- installing Python modules and binary extension modules
I would like to add another, somewhat win/mac-centric twist: - making installers of Python & add-ons. More specifically: i'm working on a program which is going to use Python, Tk, PIL, OpenGL, NumPy, Pmw, and some custom code. I'd like to be able to make a single installer which installed all of those parts, not necessarily frozen. For all of the extensions above, I think that I can generate .WSE files (the input to the WISE installer maker, free for Python extensions) which do the job, starting with Python's, and assuming I or someone else can figure out how to do the Tk bit. I'm sure this kind of thing would be useful in the mac world as well, where even fewer users have compilers. Wouldn't this sort of thing be useful in Unix as well, in some distribution models? I think so, judging from the efforts of the Digital Creations folks and their binary porting kit for Zope (from http://www.zope.org/Download/Contrib). Note that this is a different kind of distribution -- it's a distribution of applications for users, not of extensions for Python programmers. --david
I would like to add another, somewhat win/mac-centric twist:
- making installers of Python & add-ons.
More specifically: i'm working on a program which is going to use Python, Tk, PIL, OpenGL, NumPy, Pmw, and some custom code. I'd like to be able to make a single installer which installed all of those parts, not necessarily frozen.
The package installer we are currently discussing could handle that as well - almost. It should in any case be possible to install several packages at the same time; otherwise packages with circular dependencies could not be installed at all. So if the installer could also treat an archive of packages (in whatever convenient format), it would be easy to set up distributions of multiple packages. The reason I said "almost" is that the Python interpreter must always be there first. At least for Unix, I see no way around this, and for other platforms I don't know. And (again for Unix) I don't think anyone would object to install two things for some application. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------
On Fri, 18 Dec 1998, Konrad Hinsen wrote:
The package installer we are currently discussing could handle that as well - almost. It should in any case be possible to install several packages at the same time; otherwise packages with circular dependencies could not be installed at all. So if the installer could also treat an archive of packages (in whatever convenient format), it would be easy to set up distributions of multiple packages.
The reason I said "almost" is that the Python interpreter must always be there first. At least for Unix, I see no way around this, and for other platforms I don't know. And (again for Unix) I don't think anyone would object to install two things for some application.
I haven't had a chance to look at all the proposals in detail, but I just wanted to remind folks that not all "extensions" are really Python extensions, but they'd be nice things to have in a distribution anyway -- anything from non-Python specific libraries (netcdf, gd, t1lib, whatever) to large things like Tcl/Tk. Tcl/Tk is especially important for the usual reasons. In a word, some thought should be put into thinking about other non-controllable systems (e.g., no matter what Greg W says, Ousterhout isn't going to follow his recommendations =). I don't think we can or should be all-encompassing, but *thinking* a bit about these problems could avoid some pitfalls. --david
participants (4)
-
David Ascher -
Fred L. Drake -
Greg Ward -
Konrad Hinsen