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 >simpler. 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. -Barry
Attachment:
signature.asc
Description: PGP signature