[Distutils] "Python Package Management Sucks"

[Phillip J. Eby]

At 08:08 PM 10/2/2008 +0100, Floris Bruynooghe wrote:
>On Thu, Oct 02, 2008 at 10:05:49AM -0400, Phillip J. Eby wrote:
> > I don't see how this is remotely relevant to how Python works or how
> > people use (and have used) Python over the decades.  Data files in
> > package directories is something I've seen in Python since, oh, 1997 or
> > so.  If it were a mistake for Python, I think somebody would've noticed
> > by now.
>
>Well, maybe someone just did notice!  I don't see why you disagree so
>strongly with this as it is entirely in line with providing separate
>source tree locations for differents types of data which you are in
>favour of.
>
>Specifiying that this would be the recommended way and providing an
>API to deal with it doesn't mean you forbit the old way.  You'd still
>be able to dig around with __file__.  Even if any GNU/Linux packagers
>will try and convince upstreams not to do so.

We're actually in "violent agreement" here regarding what is to be 
done at a practical level.  Linux packagers want it one way, 
developers want it another, and both can have what they 
want...  unless they want the other guys to agree their way is the 
"right" way of doing it.  ;-)

That is, the Linux packagers appear to be upset and offended by the 
mere idea that anyone should consider the Python way to be correct, 
but it's not reasonable to expect people to change their minds, any 
more than it's reasonable to exepct the Linux packagers to agree the 
Python way is the right way and that everything they've been doing is 
wrong.  (And if you respond to this idea by thinking that it would be 
because the Linux packagers are *right*, then you're simply 
illustrating my point.)

Now, on a practical level, if what you are trying to say is that 
everybody should access all data strictly through some new API 
created for that purpose, then that's a non-starter for practical 
reasons, rather than ideological ones.  Even setuptools doesn't 
*require* that people use an API to access their static data, and 
does its darnedest to support that use case.

And, if you want a new spec to actually *replace* setuptools, then 
you're going to have to be very careful about what setuptools 
features are dropped, or the spec is unlikely to go from "de jure" to 
"de facto".