[Distutils] Deprecate MANIFEST.in

[P.J. Eby]

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.