[Python-Dev] Status of packaging in 3.3

Thu Jun 21 15:23:26 CEST 2012

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