Le samedi 30 janvier 2010 à 19:20 -0500, Barry Warsaw a écrit :
> 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.
Co-locating data with an API to access it brings Python on par with what
Java can do. That’s not really a good reference, I’m afraid, but it
still means progress.
> The advantage of
> using an API is that it can abstract away changes in policy or practice.
Indeed but it would require to stop developing for a moment and try
designing. I have stopped following the distutils developments when
people proposed to introduce yet another layer of symlink farms to work
around the current design issues of pkg_resources; I have stopped hoping
to see something correct come of upstream since then.
> >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.
It’s a hammer to crush a mosquito. The only thing you need is a few file
paths, and there has been a cross-language way to do that for decades:
string replacement. When a solution turns out to be more complex and
less flexible than string replacement, there’s a big problem with it.
> 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.
If you have some time, please have a look at e.g. the hamster-applet
upstream packaging, and tell me what’s complicated with it.
I’m afraid the main problem Python developers find with it is that it’s
not written in Python. So it’s more a NIH problem - the same Java has.
> >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.
Indeed, but there are some projects just as complicated out there, and
apart from (an arguably high number of) upstreams who like to make their
life more complicated, they don’t need 10000 lines of build scripts.
> >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.
How is the following YAGNI?
AC_CONFIG_FILES(foo.py)
--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=