[Python-Dev] Status of packaging in 3.3
Tarek Ziadé
tarek at ziade.org
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
More information about the Python-Dev
mailing list