Re: __file__ is a disease
Il giorno sab, 30/01/2010 alle 22.56 +0100, Josselin Mouette ha scritto:
> Le samedi 30 janvier 2010 à 21:40 +0100, Pietro Battiston a écrit :
> > In my ignorance, what I've exposed is the only way I know to get things
> > working as I want, so I'll be happy to get in touch with better
> > designs... for me, so far, __file__ may very well have been a hack, but
> > certainly not a plague.
>
> Maybe you don’t understand it is a plague, because you are not trying to
> package the things you write with __file__ for a distribution.
Not only I did try (and apparently succeeded) packaging some things I
wrote for a distribution (called Debian, some of you may have heard
about it), but I developed my "style" of packaging - which may certainly
have its flaws - explicitly thinking to something that would
- work uninstalled,
- work installed, _and_
- reduce the packaging work to the minimum
> The
> location of module files on the system should be a hidden implementation
> detail. Because of __file__, it is not and this implementation detail
> has to be exposed by packaging tools, restricting what they can do in
> ways you don’t imagine, making it impossible to just abstract them
> behind the “module” concept - which is the only one that should matter
> for a programmer.
I use __file__ exactly in detecting the case in which there is _no_
packaging tool involved.
I perfectly know that this hack - like every hack - has its drawbacks:
if the binary happens to be in the same folder of a folder called
"stuff" which contains a file called "$appname.svg", _then_ it will
erroneously think it's running uninstalled. I consider this a minor
problem, but feel free to point out anything I'm missing.
>
> Python is the only widespread high-level language to do that. I’ve never
> seen a Perl, Java or C# module look for its installation path before
> deciding what to do. In these languages, modules are abstract objects
> and you can do whatever you want with them on the filesystem without
> changing any line of code. Believe me, I love the Python language, but
> the interpreter is plagued with such issues.
>
Actually, this is the only case in which I use __file__, and apparently
you are much more competent than me about Python. So I have no reason to
not believe you, in general.
>
> Going back to the topic, please try using autoconf, waf or even cmake to
> distribute your modules. These tools were designed to abstract things
> like filesystem locations and to generate everything needed at
> installation time. Python-specific tools like setuptools are not able to
> do that, not unless you bundle specific scripts with your packages.
>
I find setuptools much more elegant, I like its ease of maintenance, I
experienced it is easily extendable, I trust that if it has flaws they
will get fixed... but most importantly for our discussion, if I did use
some of those systems that you suggest (and that I frankly thought were
just obsolete stuff still hanging around and nobody would adopt
voluntarily for a Python app today), I think I would still use __file__
to know when I'm running uninstalled.
Pietro
Reply to: