[Distutils] Access to Python config info

[John Skaller]

At 10:49 16/12/98 -0500, Fred L. Drake wrote:
>
>John Skaller writes:
> >         1) does the OS support symbolic or hard links?
>
>	import os
>	hasattr(os, "link")
>	hasattr(os, "symlink")
>

        HOW do you know this works? HOW do you know
that the method is not, in fact, present, but doesn't work?
WHERE is the standards document that specifies the
precise semantics of the 'os' interface??

        This technique doesn't seem very reliable. :-(

> > It may be the proper place for the answer is not in sys.config,
> > but in os. But the os module can compute the answers from
> > sys.config.
>
>  For most of this, probably so.  Recall also that Guido & others
>recommend "feature tests" to determine the availability of
>functionality rather than having a separate flag to indicate
>availability.  There are many ways in which this is more reliable and
>maintainable, 

        And some in which it is not reliable :-(

>though what we're currently describing as sysconfig
>remains pertinant.  I would expect sysconfig to be used mostly by
>things like distutils and not by typical programs.  Hence, it would be 
>good for os to not import it.

        That may be so. However, 'feature tests' are useless
for meta-programming. What I mean is: suppose one generated
some code. If it had to be different depending on 'features',
one could do the feature tests and generated it that way;
but this would only work on the current platform.

        If you were generating code for someone else;
then the feature tests would be useless ... unless they
were done _by_ the generated code.

        Which is the autoconfig nightmare all over again.

        What Guido is recommending is exactly like the
old fashioned DOS driver problem: test the video, or printer
to see what kind it is, and configure a driver: usually
by selecting it from a list a mile long _supplied with
every single program_.

        I don't think this is precisely the way to do it.
Dynamical feature tests are fine if they are done ONCE
on installation; and present the results in a platform
independent way. All modern operating systems have an abstract
device driver API, and the _operating system_ installs the
appropriate driver once when it is configured.

        With any luck, the configuration record can be ported,
so it is possible to generate code for any configuration,
(i.e. on a remote host): the generator _might_ optimise
the code my providing some dynamic testing (of the
configuration record on the client).

        Of course, the reliability of this mechanism
does depend on establishing standards, and then
making the implementation(s) comply.

        There's no reason the configuration module
shouldn't do these dynamical tests _as implementation
details_ of the implementation of a standardised API.
If they're appropriate.

        _I_ don't want to do this hackery in code,
however. It's too much like a bag of trickery.
I'd be happy with a module containing:

        def has_symlinks():
               import os
	       return hasattr(os, "link")

with a _specification_ of the function has_symlinks
because this would allow me to create an alternate
implementation (which could, for example, use a
data record to represent the configuration of
some remote system).

Does this make sense?
-------------------------------------------------------
John Skaller    email: skaller@maxtal.com.au
		http://www.maxtal.com.au/~skaller
		phone: 61-2-96600850
		snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia