[Distutils] Symlinks vs API -- question for developers

[Paul Moore]

2008/10/17 Barry Warsaw <barry at python.org>:
>> So once again, I think this boils down to these questions: if we have a
>> small library whose sole purpose is to abstract a data store so you can
>> find out where a particular non-code file lives on this system will you
>> use it?
>
> I would.  I apologize for not having followed the discussion that closely,
> but as an application developer, I would really like an API that hides all
> the location nonsense from me.  As familiar as __file__ is, it's a fragile
> hack.

I'd like an API, as well. It's probably the only truly cross-platform
approach. Having said that, a key question is, what precisely is
needed here? Python 2.6 has pkgutil.get_data, which abstracts the idea
of grabbing the content of a file. There's not much else that can
realistically be supported by fully general PEP 302 style loaders, so
you have to start either (1) requiring additional functionality from
loaders, or (2) restricting usage to filesystems, and losing the whole
concept of a "loader protocol" which PEP 302 provided. (And that way
lies incompatibilities with py2exe, which is very common on Windows,
and zipped eggs, as well as possibly other more obscure cases).

I'd fully support the development of an API for data access, but I'd
suggest that it should take the form of a PEP extending PEP 302, plus
an implementation in core Python (pkgutil is the obvious place),
rather than being restricted purely to an external module like
setuptools. Of course, having an external implementation for use in
older versions of Python which don't have the API in core, would be
fine, but the aim should be the core. (Otherwise, it's adding a
dependency to projects that otherwise don't need it).

Paul.