RetroSearch Browse

Thu Jun 21 15:23:26 CEST 2012 · https://mail.python.org/pipermail/python-dev/2012-June/120542.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2012-June/120542.html below:

[Python-Dev] Status of packaging in 3.3