On 6/21/12 2:45 PM, Dag Sverre Seljebotn wrote:
Guido was asked about build issues and scientific software at PyData
this spring, and his take was that "if scientific users have concerns
that are that special, perhaps you just need to go and do your own
thing". Which is what David is doing.
Trailing Q&A session here: http://www.youtube.com/watch?v=QjXJLVINsSA
if you know what you want and have a tool that does it, why bother using
distutils ?
But then, what your community will do with the guy that create packages
with distutils ? just tell him he suck ?
The whole idea is *interoperability*, not the tool used.
Generalizing a bit I think it's "web developers" and "scientists"
typically completely failing to see each others' usecases. I don't
know if that bridge can be crossed through mailing list discussion
alone. I know that David tried but came to a point where he just had
to unsubscribe to distutils-sig.
I was there, and sorry to be blunt, but he came to tell us we had to
drop distutils because it sucked, and left because we did not follow
that path
Sometimes design by committee is just what you want, and sometimes
design by committee doesn't work. ZeroMQ, for instance, is a great
piece of software resulting from dropping out of the AQMP committee.
That will not work. And I will say here again what I think we should do
imho:
1/ take all the packaging PEPs and rework them until everyone is happy
(compilation sucks in distutils ? write a PEP !!!)
I think the only way of making scientists happy is to make the build
tool choice arbitrary (and allow the use of waf, scons, cmake, jam,
ant, etc. for the build). After all, many projects contains more C++
and Fortran code than Python code. (Of course, one could make a PEP
saying that.)
Right now things are so horribly broken for the scientific community
that I'm not sure if one *can* sanely specify PEPs. It's more a
question of playing around and throwing things at the wall and see
what sticks -- 5 years from now one is perhaps in a position where the
problem is really understood and one can write PEPs.
Perhaps the "web developers" are at the PEP-ing stage already. Great
for you. But the usecases are really different.
If you sit down and ask your self: "what are the information a python
project should give me so I can compile its extensions ?" I think this
has nothing to do with the tools/implementations.
And if we're able to write down in a PEP this, e.g. the information a
compiler is looking for to do its job, then any tool out there waf,
scons, cmake, jam, ant, etc, can do the job, no ?
Anyway: I really don't want to start a flame-war here. So let's accept
up front that we likely won't agree here; I just wanted to clarify my
position.
After 4 years I still don't understand what "we won't agree" means in
this context. *NO ONE* ever ever came and told me : here's what I want
a Python project to describe for its extensions.
Just "we won't agree" or "distutils sucks" :)
Gosh I hope we will overcome this lock one day, and move forward :D
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
