Nate wrote: > It's not even crucial to me that these be fixed, but before I continue > to hack up the platform string, I wanted to ask the SIG to address these > issues and hopefully decide on a standard. That way, I can at least > implement patches in my app that will be compatible with whatever (if > anything) is decided.
Some discussion on ways to achieve different builds was done last year. Lots of things were discussed and a few decisions. I fear the wrong decision about platform naming standardization is going to be made with PEP-345. That is, abandoning traditional description via metadata, and replacing it with the ability to embed python sub-system hacks. It's cheap. And disrespects prior Python Metadata art. Already in Python Metadata, there's a wealth of platform information that could be used and extended to make decisions on platform conditional builds. Thus helping to solve your particular problem. For example, look for the "Platform:" keyword below.. --------------------------------------------------- Metadata-Version: 1.0 Name: tiddlyweb Version: 0.9.96 bits of stuff. Home-page: http://pypi.python.org/pypi/tiddlyweb Author: Chris Dent Description: TiddlyWeb Home Site: http://tiddlyweb.com/ See also: http://tiddlywiki.org/wiki/TiddlyWeb For installation instructions see http://tiddlyweb.peermore.com/ .... Platform: Posix; MacOS X; Windows --------------------------------------------------- Those constants could be extended or reused to do conditional builds. For example, in a setup.cfg, specify: [Build Posix] command=buildit.sh [Build MacOS X] command=buildosx.sh [Build Windows] command=buildw.bat Unfortunately, the guys who make the decisions on the PEPs don't seem to want to extend this way. Perhaps because they (wrongly) think it might lead to a bikeshed. I can't see how it would. This to me (existing art), makes sense: > Platform: Posix; MacOS X; Windows Not using these terms and resorting to i386 for mac and x86 or i686 for Windows is really strange. We had everything right there in front of us before. Anyway... I looked through Galaxy, and there is no setup.py file. So I think an installation could be totally achievable with via a modified Metadata file looking like this: ---------------------------------------------------- > Name: Galaxy > Home-page: http://bitbucket.org/galaxy/ > Source-Repository: hg:http://bitbucket.org/galaxy/galaxy-dist/ > Platform: Posix; MacOS X ---------------------------------------------------- and a setup.cfg looking like this: ---------------------------------------------------- [postinstall] script = run.sh ---------------------------------------------------- I wish I could say that I had it working today. I don't unfortunately. I've been trying to learn the mercurial api for checking it out etc etc. I'm a humble hacker doing this for my own enjoyment. And getting paid 50 ruppies from work too. But a whole install of a package as complex as Galaxy impwo could quite easily be done by pushing all the hard work back to mercurial. Then chaining of to your run.sh at the end. My hacking has started on http://bitbucket.org/djlyon/original-setup.py-with-metadata/src/tip/install_from_pkginfo.py So there's some way to go... Regards David _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
