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 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
