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".