At 11:18 PM 4/6/2009 +0900, David Cournapeau wrote:
P.J. Eby wrote:
> At 08:08 PM 4/6/2009 +0900, David Cournapeau wrote:
>
>> My use case is very simple, and yet very common. If you have your
>> sources in a VCS system, say svn:
>>
>> python setup.py sdist # put everything under svn into the tarball
>> cd dist && uncompress tarball && python setup.py sdist # the tarball is
>> not the same
>
> Does this actually fail under setuptools? It should not, as RPM
> building from an sdist would then fail, and there was code
> specifically added to ensure that use case works.
>
> Have you actually tested this, or are you simply theorizing?
I had some recent failure with paver + numpy.distutils + setuptools
combination as late as last week. I am not saying it is setuptools's
fault (it may well be a problem in numpy), but I can't know for sure
because there are many different ways to generate this list of sources.
The problem is not doing it with VCS as much as there are many ways in
different conditions that only a very few people understand as of today.
As a numpy developer who messes quite a bit with distutils and
numpy.distutils extensions, I hope we can get rid of all this magic as
much as possible. It is ok for *tools* to be magic, as long as they
write their *data* to a commonly understood and specified format. But
for now, setuptools enforce some behavior that other tools can't mimic,
because setuptools' way is implementation defined. And for other parts
of packaging, maybe numpy.distutils is implementation defined, without
the possibility for other tools to mimic this either.
That's why IMHO distutils should be as straightforward as possible, so
you can build up things on top of it. Some people like setuptools'
behavior w.r.t VCS; but it should be possible for my package and for my
potential distutils extensions to stay compatible with distutils,
whether I am using setuptools or not. Otherwise, when there are N tools
which are all implementation defined for packaging, it becomes
intractable very quickly.
I agree with you. But I 100% disagree with Tarek that the way to get
there is by refactoring the distutils. The distutils are stable
(i.e., dead and obsolete) and need to be *replaced*, not refactored.
We need a new source manifest format and to deprecate the distutils
as a whole, not add an API to it and deprecate the parts that actually work.
Nobody is arguing that distutils (or even setuptools) is the "right"
way to do things. But you can't get to the right thing by working
forward from the wrong... you've got to work backwards from the right.
That means creating an installation manifest format that is 100%
explicit, and then having tools (including distutils/setuptools
commands, and plugins for other build systems) that can generate that
manifest, as well as tools to install files according to different
platforms' predilections.
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
