[Distutils] Access to Python config info
Wed, 23 Dec 1998 00:10:15 +1000
>[example has_symlinks() elided]
> But this can be written on top of feature tests. Why not?
because it cannot be done.
> def has_symlinks():
> global has_symlinks
> import os
> if hasattr(os, "symlink"):
> has_symlinks = true
> return 1
> has_symlinks = false
> return 0
Obviously, this does not work. It tests if there is
a symlinks attribute in os, not what should be tested:
1) if there is an attribute symlinks, it works according to spec
2) if there is not, then the os doesn't support symlinks
To perform (1) would require actually creating some symlinks,
and seeing if they 'worked'. This is what autoconf does;
it tries to compile various features, and it tests them
as well (where they're _apparently_ available, and where it
is possible to do a short test).
It would be much easier to _document_ that
the symlinks attribute is present if and only if
creation of symbolic links is supported with
semantics XXXX (fill in specification here).
Then I could rely on the above code.
To perform (2) is hard, but might involve using shell scripts.
(Assuming you have a reliable way of launching them :-)
> Have you created a list of the system aspects that this is desirable
>for? Is the list *finite*?
No. I just keep running into problems.
And, obviously, it is desirable to have
a finite list: tradeoffs are necessary.
>It may well be, but there will be a lot
>of disagreement over what it should be.
yes. But there is nothing new here :-)
>For now, let's call this the
>"features" module. Are you ready to propose an API?
No. But I will work on it with others.
I do have some architecture developed in interscript
for this: several frames for different categories
with some work done on building these frames,
but I'm not actually using any of it.
You might start by reading the relevant sections
in the online interscript doco. Then there
is something concrete to discuss.
It's quite clear that the separate 'compilers'
stuff ought be part of this(but isn't, in interscript 1.0a7-9).
>I'm sure several
>of us would be willing to read it and carefully consider it (I will,
>though it may not sound like it;). I think the biggest problem is
>defining it in a way that provides more information or more convenient
>access to the information represented.
Yes, I agree. One way to help that process is to try to
_use_ an actual implementation. I have an implementation,
but I'm not using it. I could use help structuring it;
doing so requires the combined knowledge of many people
with experience on many different platforms.
I, by myself, do not have wide enough experience.
I do have one comment to guide your thoughts.
Consider JPython everywhere. Don't assume CPython.
John Skaller email: email@example.com
snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia