[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: __file__ is a disease

On Jan 31, 2010, at 01:09 AM, Josselin Mouette wrote:

>pkg_resources allows to do things correctly, but I find it too complex;
>it’s no wonder why people still hack stuff around __file__: it’s much

I think it's not so much that pkg_resources is complex, but that it has a lot
of extra API that most people won't need.  Hopefully the distutils-sig will
distill the essential pieces of that and push it into the stdlib.  I was
trying to see if you objected to the specific explicit use of __file__ or the
concept of co-locating data files with the source code, since that violates
the FHS, but isn't really changed by use of pkg_resources.  The advantage of
using an API is that it can abstract away changes in policy or practice.

>Basically, I’d say it tries to address the problem at the wrong level:
>build/installation issues should be addressed by the build system, not
>by the code.

Except that this is where build/installation and code requirements intersect.
The code at run time needs certain data files.  It doesn't really care where
they are, but it has to guarantee that it can find them.  The installation
system may care deeply where such files go so it has to communicate this to
the code at run-time.  Using an abstraction like pkg_resources helps bridge
that gap.

>> I've never used waf or cmake, but tools like autoconf and scons are
>> not trivial systems to use, modify or debug. I don't think that they
>> make life easier for a robust open source project.
>I beg to disagree. For a simple project, the autotools use files just as
>light and simple as setuptools, and if you look at a few sample Python
>projects using them, you will see the amount and the complexity of build
>scripts is similar.

Maybe.  IME though, many folks who are very comfortable contributing Python
code to a project run away in abject fear when asked to update autotools
files.  IMO, they're a necessary evil for complex C or C++ projects, but way
too heavy for simple Python libraries or applications.

>And as soon as you are not dealing only with pure Python code, the
>difference becomes dramatic. For example the absence of pkg-config
>support in setuptools makes it require specific code for each and every
>dependency - except those that provide dependency information in the
>Python-specific egg-info format, ha, ha.

I guess when you're talking about more complicated projects, with mixes of
various types of build artifacts, then the build system will necessarily have
to be more complex.

>There are huge projects that use the autotools without needing to jump
>through hoops. A simple look at NumPy and its 10000+ lines of specific
>Python code just to be able to build the C pieces should be enough to
>convince anyone to use a better tool.

Maybe so, but that seems like an extreme example for the Python universe of
stuff.  Most libraries don't need anything nearly as complicated.

>I’m not implying the autotools don’t have flaws: the insanity of libtool
>bugs, the arcanes of m4 and the gazillions of broken m4 scripts that lie
>around… But these flaws are about features that don’t even exist in
>Python-specific tools.

For most Python libraries and applications, they're YAGNI anyway.  If there
are specific problems with Python tools for the majority of straightforward
Python libraries, let's fix those tools.  But I think they mostly work, and
where they don't, the distutils-sig is paving the way of the future.


Attachment: signature.asc
Description: PGP signature

Reply to: