Chris Withers wrote:
David Cournapeau wrote:
Chris Withers wrote:
"even" seems to imply this is a basic requirement. I wonder how many people are rolling out python apps on Win64? I'm certainly not...
Even was maybe a bit strong. Concerning win64, the first release of numpy we did for win64 has been downloaded 3000 times,
By what? I'm always sceptical about the download figures on PyPI, and other places. I wonder how many bots are sucking down every .exe or .msi they can find to check for viruses or the like?
Sourceforge numbers. Besides, I can assure you that there is a lot of interest in windows 64 for scientific computing (in terms of people willing to pay).
You should probably look at buildout, you may find your like getting a lot easier. Yes, the docs suck. I even promised to do something about that back at PyCon, sadly time has not been kind to my promises...
The docs are indeed less than ideal - everytime I tried to read something about buildout, I could not even understand what it was about :) But even though, I doubt buildout is what I am after: chroot-like sandboxing for example, is crucial (and for what it worths, it is a standard practice in the unix deployment world). What I use is kind of besides the point, though. What matters is to have a standard core on top of which people can build their tools: a core in the stdlib, and buildout-based, scons-based, whatever-based tools on top. If you have an API to retrieve where things are put, how they are built and so on, everyone can be happy with the tool he prefers.
Well, buildout.cfg is exacltly that file for me, for both cases ;-)
I may not have been clear: by single file, I mean an installer, which needs to work offline, and is as integrated as possible in the user system. This mean msi, dmg, rpm, etc... A buildout.cfg can't possible be further from what I want in those cases. David