[Distutils] Deprecate MANIFEST.in

[Floris Bruynooghe]

On Tue, Apr 07, 2009 at 10:09:33AM +0200, Lennart Regebro wrote:
> On Tue, Apr 7, 2009 at 09:40, David Cournapeau
> <david at ar.media.kyoto-u.ac.jp> wrote:
> > Lennart Regebro wrote:
> >>
> >> "Lower system"? What would that be? This is about if we should support
> >> getting a file list from the VCS or not to determine what files should
> >> go in a sdist.
> >
> > We can argue all day long
> 
> Possibly. I can't say we are arguing though. You are just saying that
> you don't agree, but you still come with no arguments for your
> standpoint or against mine. It's obvious that you have made up your
> mind, but you don't know why. You may be correct, but to convince me
> you need concrete arguments. Not fuzzy broad statements that you fail
> to explain.

Sorry if I am going to repeat something but I haven't followed the
entire discussion to the last detail.  But since I agree with David
I'll try to add my arguments.

> > but since there is a disagreement, there is
> > only two issues: either someone decides for one behavior or the other,
> > or we acknowledge our difference and decide on less ambitious goals to
> > build other tools above.
> 
> Less ambitious goals? We are discussing if the VCS should be a part of
> determining the list of files that goes into a distribution or not.
> This is not in any way ambitious. You claim that it under no
> circumstance should be a part of it, but you have no arguments for
> that standpoint. I claim that it is a good and reasonable way to
> determine which files should be included, unless the files are
> otherwise specified.
> 
> How can we have any "less ambitions" goals than this?

The VCS is an external piece of software outside of Python and the
distutils.  There also isn't just one VCS, there's many of them and
all of them are on different release schedules which differ from
Python's and/or distutils's release schedules and can thus break API,
or datastore semantics at any time (I think this was demonstrated with
setuptools and svn 1.5 but not sure since I don't use setuptools).
Therefore for distutils to actually depend on a VCS to function seems
dangerous and a massive maintenance burden.

This can of course be fixed with plugins etc like setuptools does.
But the basic problem stays the same, distutils can be broken by
external software.

I do acknowledge that for some people this is exactly what they want
and indeed can see the benefit of integrating with your VCS.  So yes,
that should be made possible.  But as has been said numerous times
distutils should move to some common data formats so that different
tools can be used to provide this type of extra-sweet functionality
for a subset of the users.


> >>  I have a hard time envisioning anything "lower" than
> >> that.
> >
> > Why so ? Few packaging system use the VCS as the lower system to know
> > what goes in a distribution, most of them (regardless of the platform:
> > windows, unix, mac os x) uses something more low level than this at the
> > implementation level.
> 
> I totally fail to see how this is in any way "lower", and repeat my
> question: "Lower system"? What would that be? What is a "lower system"
> in determining a file list? I suggested a three step process:
> 
> 1. If there is explicit definitions, use that.
> 2. If not, then if there is a VCS, use that.
> 3. If not, include all files except those extensions that are known to
> be temporary files.
> 
> Where in this is there a "lower level"?

Number 1 could be the simple lower level, a list of files (I'm not
saying this is a good choice, I haven't studied all the issues good
enough).  That way the tool you use to consume setup.py (or
whatever it becomes) can construct this list from your VCS in an
automated fashion if you do like that.  But it avoids having the VCS
dependency inside distutils.


Regards
Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org