Re: [Python-Dev] cpython (2.7): - Issue #17086: Backport the patches from the 3.3 branch to cross-build
I personally agree that huge changesets aren't good. But I can also see the problem of cross compiling should be sooner or later addressed. I'm fairly interested in cross building python on android too. A point to support cross compiling (instead native build arm-on-arm) could be android doesn't provide (to my knowledge) a native toolchain: that's a quite large target. And assuming arm equals unix so there's always an installed or installable compiler on it is not always the case. If I can suggest a simple solution that'd be a simple makefile to compile python (I have one on my own): no "configure" magic involved more akin to the windows build style (yes, I've just said the W* word). I hope this helps, antonio - Issue #17086: Backport the patches from the 3.3 branch to cross-build the package. You aren't supposed to add new features to bugfix branches. Did you have a specific reason to do this? One of the reasons for the long maintenance period on 2.7 is to keep it building as the underlying platforms change. With the rise of ARM systems, being able to reliably cross-build Python 2.7 for ARM from an x86_64 system is fairly important. I would like to see a better argument for this. The rise of ARM systems is the rise of ARM systems powerful enough to build Python without cross-compiling (which is why we *now* have ARM buildbots). The very small ARM systems which need cross-compiling have existed for decades. That said, as a procedural point for build related new features in 2.7, I agree they should be proposed, with an explicit rationale, on python-dev before proceeding with the commit. I think this huge changeset should be reverted. It's a complete failure in terms of procedure and following the rules. "Just because it can be useful" is not a good enough reason to violate our release model without even asking. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/a.cavallo%40cavallinux.eu ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] BDFL delegation for PEP 426 (PyPI metadata 1.3)
In doing the detailed review of PEP 426 as BDFL-Delegate, I keep noticing confusing problems with the current spec that mean I want to become a *co-author* on the spec, rather than explaining to the current authors the aspects I object to, until they produce a version that I'm happy with (this is frustrating for the authors as well, since several of the problems have been inherited from the previous version of the spec rather than being new in the current version). Now, Guido's authored and accepted his own PEPs in the past, but to date we've avoided letting anyone else do that. Since I *definitely* want to co-author the new metadata PEP (mostly to address issues with the version specifier section and to include the *rationale* for changes, rather than merely listing them as previous versions of the metadata PEPs have done), that means one of the following needs to happen: - someone else volunteers to be BDFL-Delegate for PEP 426 (MvL, perhaps?) - I get clear approval (perhaps from Guido?) to be both co-author *and* BDFL-Delegate for PEP 426 Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BDFL delegation for PEP 426 (PyPI metadata 1.3)
On Sat, Feb 2, 2013 at 10:04 PM, Nick Coghlan wrote: > In doing the detailed review of PEP 426 as BDFL-Delegate, I keep > noticing confusing problems with the current spec that mean I want to > become a *co-author* on the spec, rather than explaining to the > current authors the aspects I object to, until they produce a version > that I'm happy with (this is frustrating for the authors as well, > since several of the problems have been inherited from the previous > version of the spec rather than being new in the current version). > > Now, Guido's authored and accepted his own PEPs in the past, but to > date we've avoided letting anyone else do that. Since I *definitely* > want to co-author the new metadata PEP (mostly to address issues with > the version specifier section and to include the *rationale* for > changes, rather than merely listing them as previous versions of the > metadata PEPs have done), that means one of the following needs to > happen: > > - someone else volunteers to be BDFL-Delegate for PEP 426 (MvL, perhaps?) > - I get clear approval (perhaps from Guido?) to be both co-author > *and* BDFL-Delegate for PEP 426 I don't know or care much about PyPI metadata, so do what you feel is right. If you are uncomfortable being PEP-uncle *and* -author, find another author or another uncle. But since it doesn't affect the language or library, it's fine with me if you are both. :-) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BDFL delegation for PEP 426 (PyPI metadata 1.3)
On Sun, Feb 3, 2013 at 4:37 PM, Guido van Rossum wrote: > I don't know or care much about PyPI metadata, so do what you feel is > right. If you are uncomfortable being PEP-uncle *and* -author, find > another author or another uncle. But since it doesn't affect the > language or library, it's fine with me if you are both. :-) To clarify what will happen if I handle both jobs: I'll bug a few specific people like Vinay Sajip (distlib), and MvL or Richard Jones (PyPI) to at least glance over it, as well as giving distutils-sig, catalog-sig and python-dev one last chance to comment on my revised draft. Then, wearing my BDFL-Delegate hat, I'd decide what feedback I considered worth addressing and what could be safely ignored (or postponed to the next time the metadata gets updated). I don't expect anything I want to do to be particularly controversial, but I think it's worth trying to get it right (even if it delays wheel support in pip for a few more weeks). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
