Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
Martin v. Löwis mar...@v.loewis.de writes: The major difference in the do it yourself attitude is that Mac user get a compiler for free, as part of the operating system release, whereas for Windows, they have to pay for it (leaving alone VS Express for the moment). JOOI why ignore the express versions of the MS compilers? All (I think) MS compilers are available for free in command line versions - it's the GUI tools you pay for. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
In article 4bc54f4f.4090...@v.loewis.de, Martin v. Lowis mar...@v.loewis.de wrote: Wasn't that problem fixed weeks ago? The installer image has been available there since several days after the release. And the link seems fine now. The inherent problem remains. There is no binary for 2.7b1, for example. The last binaries produced in the 2.7 testing process were for 2.7a2. That's true. But there wouldn't be a traditional OS X installer for 2.7b1 anyway since it turns out it is not possible to build a multi-arch installer without patching because of a bug that wasn't caught before the code cutoff since there are no OS X buildbots that test that configuration. But, at the moment, there aren't any OS X buildbots at all, are there? That *is* something that the PSF could help with. I would be happy to help with that myself, although my time to do so will be very limited for the next few weeks. -- Ned Deily, n...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On 14/04/2010 07:11, Martin v. Löwis wrote: Why is it unavoidable that the Mac build will languish behind others? Because of lack of volunteers, and expertise (i.e. the experts lack time). That doesn't explain why we leave a broken link in place when we do major releases - for days usually (if not weeks) with no explanation to users. That part of the release process is broken and should be fixed. Putting some placeholder text on the release page instead of the broken link is barely any more effort at all. For the last 2.6.5 release I changed the text and removed the dead link myself. When the Mac installer was uploaded someone else put the link back. [snip...] Clearly it's not a priority given that nobody has seen fit to (or had time to) reply to this mail in three weeks. That is not surprising: none of the webmaster people would be able to answer the question. python-dev is indeed the right place to ask. Which is why I sent the email onto python-dev. However, no-one responded until Steve. All the best, Michael Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On 14/04/2010 06:13, Ned Deily wrote: In articlehq3e52$8o...@dough.gmane.org, Steve Holdenst...@holdenweb.com wrote: Why is it unavoidable that the Mac build will languish behind others? Are we supporting MacOs or aren't we? If we are, why isn't the creation of the build a part of the release process? Clearly it's not a priority given that nobody has seen fit to (or had time to) reply to this mail in three weeks. Wasn't that problem fixed weeks ago? The installer image has been available there since several days after the release. And the link seems fine now. The problem is the process that creates a new release with a 404 link to the Mac installer with no explanation. The 2.6.5 release (as always) caused several requests to webmaster from Mac users unable to download Python - which is a further waste of volunteer time as well as a cause of frustration for users. Building the Mac installer requires volunteer time which I'm not sure that more hardware will fix - compiling a full build of Python for Mac OS X (with all the Python modules like Tkinter etc) requires expertise which only a few people have. A Mac OS X machine (and location to keep it) for the buildbots is a *big* need however. All the best, Michael -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] patch for review: unittest ImportError handling
On 14/04/2010 05:49, Chris Jerdonek wrote: Hi folks, I have a patch to the unittest module for review here: http://bugs.python.org/issue7559#msg102801 (There have already been a couple rounds of discussion on how to best fix this.) This is my first patch, so any feedback is appreciated. I'm still not convinced that this isn't a backwards incompatible change - up until now, however horrible it may be, TestLoader.loadTestsFromName only raised an AttributeError when it failed to load a test. Changing it to allow it propagate ImportError means that code catching errors by handling AttributeError will be potentially broken by the fix. I'm certainly happy to discuss this here though. An alternative fix would be for a new API and deprecation of loadTestFromName. A new API could return a placeholder test that raises the original error when run - that way individual errors don't break the test collection phase but are still reported. This *could* be added to loadTestsFromName with an optional argument. By the way, in general please don't assign unittest bugs *away* from me on the tracker. I'm maintaining unittest and have been watching this issue. I haven't given it much attention recently because of getting the new features ready for the 2.7b1 release. I will certainly want to look through the patch before it is committed, if the consensus here is that changing this API to raise an ImportError is not a backwards incompatible change. All the best, Michael Foord Thanks, --Chris ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On 14/04/2010 07:17, Steve Holden wrote: [snip...] In a wider sense of to support, MacOS is certainly supported by Python. There is everything in the source code that you need to make Python run on a Mac. Just download the sources and compile them yourself. And yet we don't regard the Windows release as complete until you have built the binaries (for which service you deserve many thanks, by the way). Is the Mac platform one on which users will be happy to compile from source? I know its users are savvier than Windows users, and have a better tool set available to them, but they still seem to expect downloadable installers. Mac users definitely *do* expect installers. Building Python requires, I believe, the XCode development tools to be installed. Even then, building a full version of Python - with *all* the C extensions that are part of a Python release - is not a trivial task. All the best, Michael Foord Clearly it's not a priority given that nobody has seen fit to (or had time to) reply to this mail in three weeks. That is not surprising: none of the webmaster people would be able to answer the question. python-dev is indeed the right place to ask. I thought I'd picked this thread off python-dev. What point am I not understanding here? regards Steve -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] patch for review: unittest ImportError handling
I'd really like to see a fix that works with loadTestsFromNames - generating failing tests, for instance, and the failing tests having the full import error string in them. This doesn't preclude raising ImportError from loadTestFromName, and in fact I'd encourage that as a step towards the aforementioned loadTestsFromNames change. It is a change with the existing misguided behaviour; sometimes thats better to do than preserving compat; as you say a new API might be best overall though. I'd go with a keyword arg rather than a new function, I think. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin v. Löwis wrote: Tres Seaver wrote: Steve Holden wrote: Why is it unavoidable that the Mac build will languish behind others? Are we supporting MacOs or aren't we? If we are, why isn't the creation of the build a part of the release process? Clearly it's not a priority given that nobody has seen fit to (or had time to) reply to this mail in three weeks. Maybe the PSF should make it a priority by funding acquisition of the appropriate proprietary hardware (Mac / Windows) for the release manager. Otherwise the avaialbility of binaries is going to lag source releases forever. Tres, can you be more explicit? How would such hardware help (whom specifically)? I assumed that creation of installer binaries for a release depends on having the release manager or a lieutenant have access to the given platform (Windows, OS/X) and tools, For instance, the RM or lieutenant might only have access to such a platform part-time (e.g., only while at work, or only at home). In such a case, providing additional hardware could expedite creation of the binaries. I'm sorry if I misunderstood the issue. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvFmdkACgkQ+gerLs4ltQ5B/QCglQlANbOgn8BodKowku/aCBc0 QdgAoLQi2Ntlns/B4FdxNs0kCHC5VVqk =Xm+Q -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] patch for review: unittest ImportError handling
On Wed, Apr 14, 2010 at 2:07 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: I'm still not convinced that this isn't a backwards incompatible change - up until now, however horrible it may be, TestLoader.loadTestsFromName only raised an AttributeError when it failed to load a test. Changing it to allow it propagate ImportError means that code catching errors by handling AttributeError will be potentially broken by the fix. I'm certainly happy to discuss this here though. Thanks for your response. Michael. To understand your position better, would you view changing the AttributeError in *any* way an incompatible change (e.g. changing just the error message), or is it only changing the error type that you view as backwards incompatible? The reason I ask is that I think it's the change in what the error contains (e.g. the error message and stack trace) that is the more important part of this change -- rather than whether that information be wrapped in an ImportError versus an AttributeError. It is the information rather than the particular error type that will assist an end-developer in diagnosing future unit-test failures. An alternative fix would be for a new API and deprecation of loadTestFromName. A new API could return a placeholder test that raises the original error when run - that way individual errors don't break the test collection phase but are still reported. This *could* be added to loadTestsFromName with an optional argument. I'm not opposed to adding a new API, but I think it would be valuable if we could find a way for people to enjoy the benefit of not having the stack trace swallowed -- without having to change their code. I'm currently part of a project where the current behavior makes it harder to track down unit test failures. I imagine many developers are in a similar situation. This seems to be a bug, and such developers may be in a position where they can't change how their unit tests are run, but they're nevertheless stuck diagnosing the failures. I'm writing on the assumption that there is a way to preserve the stack trace and error message of an ImportError while re-raising it as an AttributeError. By the way, in general please don't assign unittest bugs *away* from me on the tracker. Will do. I hadn't come across any guidance re: assigning in the development workflow documentation. Maybe we should add a cautionary note about this in the documentation somewhere. In general, do all reports stay assigned to the maintainer (if a maintainer exists), or is it a per-maintainer preference on how that is handled? Thanks, --Chris ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On 14 April 2010 07:37, Paul Rudin p...@rudin.co.uk wrote: Martin v. Löwis mar...@v.loewis.de writes: The major difference in the do it yourself attitude is that Mac user get a compiler for free, as part of the operating system release, whereas for Windows, they have to pay for it (leaving alone VS Express for the moment). JOOI why ignore the express versions of the MS compilers? All (I think) MS compilers are available for free in command line versions - it's the GUI tools you pay for. I believe that the express editions don't include some of the advanced optimisations (profile guided optimisation rings a bell) which are used to build the official binaries. So if the binaries were built using Express Edition, they would be somewhat slower. That is just my recollection, however - it may be out of date or wrong. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] patch for review: unittest ImportError handling
On 14/04/2010 12:54, Chris Jerdonek wrote: On Wed, Apr 14, 2010 at 2:07 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: I'm still not convinced that this isn't a backwards incompatible change - up until now, however horrible it may be, TestLoader.loadTestsFromName only raised an AttributeError when it failed to load a test. Changing it to allow it propagate ImportError means that code catching errors by handling AttributeError will be potentially broken by the fix. I'm certainly happy to discuss this here though. Thanks for your response. Michael. To understand your position better, would you view changing the AttributeError in *any* way an incompatible change (e.g. changing just the error message), or is it only changing the error type that you view as backwards incompatible? The reason I ask is that I think it's the change in what the error contains (e.g. the error message and stack trace) that is the more important part of this change -- rather than whether that information be wrapped in an ImportError versus an AttributeError. It is the information rather than the particular error type that will assist an end-developer in diagnosing future unit-test failures. Changing the error message to provide more useful information, possibly including the original traceback, would certainly avoid the potential for incompatibility. I'd be interested in seeing what other folks here on python-dev think. An alternative fix would be for a new API and deprecation of loadTestFromName. A new API could return a placeholder test that raises the original error when run - that way individual errors don't break the test collection phase but are still reported. This *could* be added to loadTestsFromName with an optional argument. I'm not opposed to adding a new API, but I think it would be valuable if we could find a way for people to enjoy the benefit of not having the stack trace swallowed -- without having to change their code. It's a double edged sword though - it means existing users depending on the fact that this API only raises AttributeError have to change *their* code. For a new API I like Rob Collin's suggestion of a keyword argument to loadTestsFromNames that returns an error placeholder instead of raising an exception. That couldn't be put into 2.7 now though. I'm currently part of a project where the current behavior makes it harder to track down unit test failures. I imagine many developers are in a similar situation. This seems to be a bug, and such developers may be in a position where they can't change how their unit tests are run, but they're nevertheless stuck diagnosing the failures. I'm writing on the assumption that there is a way to preserve the stack trace and error message of an ImportError while re-raising it as an AttributeError. The original stacktrace could be included as part of the error message. Pretty horrible though. By the way, in general please don't assign unittest bugs *away* from me on the tracker. Will do. I hadn't come across any guidance re: assigning in the development workflow documentation. Maybe we should add a cautionary note about this in the documentation somewhere. In general, do all reports stay assigned to the maintainer (if a maintainer exists), or is it a per-maintainer preference on how that is handled? Where an issue is assigned to an existing maintainer I would wait for a response on the issue tracker or raise it here on python-dev rather than re-assigning the issue. In general issues corresponding to modules that have an active maintainer should be assigned to the maintainer. It is particularly an issue for me with unittest because I want to track changes in unittest in the unittest2 package and need to know about all changes. I'm often around on #python-dev to discuss things. All the best, Michael Foord Thanks, --Chris -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] patch for review: unittest ImportError handling
On Wed, Apr 14, 2010 at 4:12 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: On 14/04/2010 12:54, Chris Jerdonek wrote: On Wed, Apr 14, 2010 at 2:07 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: I'm still not convinced that this isn't a backwards incompatible change - up until now, however horrible it may be, TestLoader.loadTestsFromName only raised an AttributeError when it failed to load a test. Changing it to allow it propagate ImportError means that code catching errors by handling AttributeError will be potentially broken by the fix. I'm certainly happy to discuss this here though. Thanks for your response. Michael. To understand your position better, would you view changing the AttributeError in *any* way an incompatible change (e.g. changing just the error message), or is it only changing the error type that you view as backwards incompatible? The reason I ask is that I think it's the change in what the error contains (e.g. the error message and stack trace) that is the more important part of this change -- rather than whether that information be wrapped in an ImportError versus an AttributeError. It is the information rather than the particular error type that will assist an end-developer in diagnosing future unit-test failures. Changing the error message to provide more useful information, possibly including the original traceback, would certainly avoid the potential for incompatibility. I'd be interested in seeing what other folks here on python-dev think. An alternative fix would be for a new API and deprecation of loadTestFromName. A new API could return a placeholder test that raises the original error when run - that way individual errors don't break the test collection phase but are still reported. This *could* be added to loadTestsFromName with an optional argument. I'm not opposed to adding a new API, but I think it would be valuable if we could find a way for people to enjoy the benefit of not having the stack trace swallowed -- without having to change their code. It's a double edged sword though - it means existing users depending on the fact that this API only raises AttributeError have to change *their* code. For a new API I like Rob Collin's suggestion of a keyword argument to loadTestsFromNames that returns an error placeholder instead of raising an exception. That couldn't be put into 2.7 now though. I'm currently part of a project where the current behavior makes it harder to track down unit test failures. I imagine many developers are in a similar situation. This seems to be a bug, and such developers may be in a position where they can't change how their unit tests are run, but they're nevertheless stuck diagnosing the failures. I'm writing on the assumption that there is a way to preserve the stack trace and error message of an ImportError while re-raising it as an AttributeError. The original stacktrace could be included as part of the error message. Pretty horrible though. I just experimented with this myself. Couldn't we do something like the following to change the error type and preserve the stack trace -- without including the stack trace as part of the message? try: foo() except ImportError: excType, excValue, excTraceback = sys.exc_info() raise AttributeError, excValue, excTraceback Superficially this seems to have the desired effect. We could also adjust the error text to indicate that the AttributeError was originally an ImportError. The above is similar to the code you referenced in one of your comments to issue 7559-- http://twistedmatrix.com/trac/browser/trunk/twisted/python/reflect.py?rev=28196#L384 --Chris ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On Apr 14, 2010, at 10:56 AM, Michael Foord wrote: The problem is the process that creates a new release with a 404 link to the Mac installer with no explanation. The 2.6.5 release (as always) caused several requests to webmaster from Mac users unable to download Python - which is a further waste of volunteer time as well as a cause of frustration for users. As the RM, that's my fault then. When I start creating the page for a new release I will leave the Windows and Mac links commented out. I do (now wink) wait for Martin to upload the Windows installers before announcing the release, but generally don't wait for Ronald to produce the Mac images, so I leave those commented out too. When Ronald builds the Mac image and provides it to me, I'll upload them and tweak the page. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3147 ready for pronouncement and merging
On Apr 13, 2010, at 04:44 PM, Guido van Rossum wrote: Give me a couple of days; but I don't expect any problems given how the earlier discussion went. If you didn't hear from me by Friday go ahead and merge. Thanks Guido. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r80025 - peps/trunk/pep-3147.txt
On Apr 14, 2010, at 07:04 AM, Nick Coghlan wrote: Yeah, the only time it uses byte-compiled files is if the original source is missing. Setting __cached__ to None for that case as well sounds like a reasonable starting point. Cool, thanks. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On 14/04/2010 13:46, Barry Warsaw wrote: On Apr 14, 2010, at 10:56 AM, Michael Foord wrote: The problem is the process that creates a new release with a 404 link to the Mac installer with no explanation. The 2.6.5 release (as always) caused several requests to webmaster from Mac users unable to download Python - which is a further waste of volunteer time as well as a cause of frustration for users. As the RM, that's my fault then. When I start creating the page for a new release I will leave the Windows and Mac links commented out. I do (now wink) wait for Martin to upload the Windows installers before announcing the release, but generally don't wait for Ronald to produce the Mac images, so I leave those commented out too. When Ronald builds the Mac image and provides it to me, I'll upload them and tweak the page. Can we amend that to having some placeholder text saying that the Mac installer is not yet available and a link to the previous available version please. That can then be replaced with the normal link once the Mac installer is uploaded. Thanks Michael Foord -Barry -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On Apr 14, 2010, at 02:45 PM, Michael Foord wrote: Can we amend that to having some placeholder text saying that the Mac installer is not yet available and a link to the previous available version please. That can then be replaced with the normal link once the Mac installer is uploaded. You mean, on the x.y.z release page, or a separate page? I guess you're saying that it's better to include some not available yet text on the x.y.x release page than to just comment out the platform. That makes sense, and I'd be happy to do that, since I already make such a caveat in the release announcement. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On Wed, Apr 14, 2010 at 06:33:03AM -0400, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin v. L?wis wrote: Tres Seaver wrote: Steve Holden wrote: Why is it unavoidable that the Mac build will languish behind others? Are we supporting MacOs or aren't we? If we are, why isn't the creation of the build a part of the release process? Clearly it's not a priority given that nobody has seen fit to (or had time to) reply to this mail in three weeks. Maybe the PSF should make it a priority by funding acquisition of the appropriate proprietary hardware (Mac / Windows) for the release manager. Otherwise the avaialbility of binaries is going to lag source releases forever. Tres, can you be more explicit? How would such hardware help (whom specifically)? I assumed that creation of installer binaries for a release depends on having the release manager or a lieutenant have access to the given platform (Windows, OS/X) and tools, For instance, the RM or lieutenant might only have access to such a platform part-time (e.g., only while at work, or only at home). In such a case, providing additional hardware could expedite creation of the binaries. As with Windows, I personally find that building Python with all the associated libraries is blocked on getting the right libraries installed, not on getting the compilers (which are available to us for free) ... but I'm sure that easy access to hardware is an issue, too. I can provide command-line access to a Mac OS X machine but I'm not sure that's enough. Let me know if anyone wants that. Separately, I'd be happy to put forward a proposal to the PSF to fund RMs and their lieutenants with a Mac or a PC, whichever they needed to keep things moving. It's the least we can do, IMO, and hardware is just not that expensive compared to the dedication of the volunteers. If Georg, Benjamin, Martin, or Ronald are interested, please just tell me (or Steve, or the PSF board, or ...) what you want and I'll work on getting it funded. --titus -- C. Titus Brown, c...@msu.edu ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On 14/04/2010 13:58, Barry Warsaw wrote: On Apr 14, 2010, at 02:45 PM, Michael Foord wrote: Can we amend that to having some placeholder text saying that the Mac installer is not yet available and a link to the previous available version please. That can then be replaced with the normal link once the Mac installer is uploaded. You mean, on the x.y.z release page, or a separate page? I guess you're saying that it's better to include some not available yet text on the x.y.x release page than to just comment out the platform. That makes sense, and I'd be happy to do that, since I already make such a caveat in the release announcement. Yes, I mean on the release page. The issue is that the download links on the sidebar / front page go straight to the latest release page. If there isn't yet a Mac installer available, and no alternative link to get the previous version, it leaves Mac users with no obvious way to get a Mac installer *at all*. (Those who know the site well can find the previous versions themselves, but for users not intimately familiar with our site layout it is 'a challenge'.) Thanks Michael -Barry -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On Wed, Apr 14, 2010 at 07:36:25AM +0200, Martin v. L?wis wrote: In a wider sense of to support, MacOS is certainly supported by Python. There is everything in the source code that you need to make Python run on a Mac. Just download the sources and compile them yourself. And yet we don't regard the Windows release as complete until you have built the binaries (for which service you deserve many thanks, by the way). This phenomenon exists for a lot of other systems, as well. For example, we also support Solaris, but stopped providing Solaris binaries since Python 1.5 (when I last built binaries for Das Python-Buch). People still can get Solaris binaries from ActiveState or Sunfreeware; Sun also ships Python as part of the system. I personally think the Mac is pretty important, as one of the big three consumer operating systems... Is the Mac platform one on which users will be happy to compile from source? I know its users are savvier than Windows users, and have a better tool set available to them, but they still seem to expect downloadable installers. The major difference in the do it yourself attitude is that Mac user get a compiler for free, as part of the operating system release, whereas for Windows, they have to pay for it (leaving alone VS Express for the moment). Actually, I think the more pernicious factor is that a version of Python comes pre-installed on Mac OS X, which means the up-front demand is lower for a pre-compiled version. This is problematic, though, because that version of Python only gets upgraded with full releases of Mac OS X (which are not very well correlated with releases of Python, of course). So we have lots of Python installs out there that, in the absence of a precompiled binary version, can't be upgraded without installing the developer tools. However, the real difference is motivation for contribution to open source projects. You normally contribute to scratch an itch. Unfortunately, these binaries don't come out such a motiviation. So the release manager roles are either altruistic, or rely on extrinsic motivations (money, reputation). I don't know what to do about motivation but if there are barriers that we can lower, please let me know. cheers, --titus -- C. Titus Brown, c...@msu.edu ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3147 ready for pronouncement and merging
On Tue, 13 Apr 2010, Barry Warsaw wrote: I am attaching the latest revision of PEP 3147 to this message, which is also available here: http://www.python.org/dev/peps/pep-3147/ [] PEP: 3147 Title: PYC Repository Directories [] Further, pyc files will contain a magic string that differentiates the Python version they were compiled for. This allows multiple byte compiled cache files to co-exist for a single Python source file. This scheme has the added benefit of reducing the clutter in a Python package directory. When a Python source file is imported for the first time, a `__pycache__` directory will be created in the package directory, if one does not already exist. The pyc file for the imported source will be written to the `__pycache__` directory, using the magic-tag formatted name. If either the creation of the `__pycache__` directory or the pyc file inside that fails, the import will still succeed, just as it does in a pre-PEP-3147 world. [] Thank you for doing the work on this improvement. I have one wording suggestion which I hope isn't bikeshedding: up above, I think the sentence containing pyc files will contain a magic string would be clearer if it made it clear that the file *names*, not (just?) the file contents, will contain the magic tag. Isaac Morland CSCF Web Guru DC 2554C, x36650WWW Software Specialist ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On Apr 14, 2010, at 06:39 AM, C. Titus Brown wrote: Separately, I'd be happy to put forward a proposal to the PSF to fund RMs and their lieutenants with a Mac or a PC, whichever they needed to keep things moving. It's the least we can do, IMO, and hardware is just not that expensive compared to the dedication of the volunteers. If Georg, Benjamin, Martin, or Ronald are interested, please just tell me (or Steve, or the PSF board, or ...) what you want and I'll work on getting it funded. While I appreciate the offer, I don't think this is as useful as it could be. Speaking as an RM, I would happily build all three releases (source tarballs, Windows installers and Mac disk images) if I had easy access to the necessary machines and environments over the 'net, and precise instructions on how to do the builds. Ideally, those instructions would be run this script or even rolled into the current release.py script that is used to build the tarballs. I have Macs and a Windows machine. The Windows machine is not easily accessible as it's a dual-boot with Ubuntu. As stated previously, the difficult part is getting all the necessary dependencies in place and the expertise to know the steps that are required to build. A network accessible machine for Mac and Windows, where other experts such as Martin and Roland can help maintain and configure, would be ideal. That way, and of the platform experts or RM could push a button and build the installers. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3147 ready for pronouncement and merging
Isaac Morland wrote: I have one wording suggestion which I hope isn't bikeshedding: up above, I think the sentence containing pyc files will contain a magic string would be clearer if it made it clear that the file *names*, not (just?) the file contents, will contain the magic tag. That's not bikeshedding, that's picking up a mistake in the PEP :) Indeed, the magic tag only goes in the file names (the pyc files themselves contain the corresponding magic number, just as they always have). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
Michael Foord wrote: Yes, I mean on the release page. The issue is that the download links on the sidebar / front page go straight to the latest release page. If there isn't yet a Mac installer available, and no alternative link to get the previous version, it leaves Mac users with no obvious way to get a Mac installer *at all*. (Those who know the site well can find the previous versions themselves, but for users not intimately familiar with our site layout it is 'a challenge'.) I would actually use the source only release pages as a guide here. They provide a link to the download page for the last version that provided Mac and Windows binaries. This makes it clear to the downloader that the binaries are for an older version, while still making a binary version easy to find. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))
Martin v. Löwis wrote: Wasn't that problem fixed weeks ago? The installer image has been available there since several days after the release. And the link seems fine now. The inherent problem remains. There is no binary for 2.7b1, for example. The last binaries produced in the 2.7 testing process were for 2.7a2. I seem to recall there was some issue (aside from the current lack of a reliable OS X buildbot) that prevented us from regularly grabbing the head of the tree and using it to automatically build the Windows and Mac installers (to check that the installers could actually be created, preventing a repeat of the Mac situation with 2.7b1). Am I misremembering the discussion from last time this topic came up? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] patch for review: unittest ImportError handling
Michael Foord wrote: Changing the error message to provide more useful information, possibly including the original traceback, would certainly avoid the potential for incompatibility. I'd be interested in seeing what other folks here on python-dev think. Without looking at the details, my question is whether this can be ignored in 2.x and fixed for 3.x by setting __cause__ appropriately (i.e. by using the raise from syntax). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))
On Thu, Apr 15, 2010 at 12:47:50AM +1000, Nick Coghlan wrote: Martin v. L?wis wrote: Wasn't that problem fixed weeks ago? The installer image has been available there since several days after the release. And the link seems fine now. The inherent problem remains. There is no binary for 2.7b1, for example. The last binaries produced in the 2.7 testing process were for 2.7a2. I seem to recall there was some issue (aside from the current lack of a reliable OS X buildbot) that prevented us from regularly grabbing the head of the tree and using it to automatically build the Windows and Mac installers (to check that the installers could actually be created, preventing a repeat of the Mac situation with 2.7b1). Am I misremembering the discussion from last time this topic came up? Making the Windows binary build process automatic and robust is challenging if you hate Windows (like I do). Martin also made the point that it's been broken forever, so people don't seem to care :). ISTR Martin just makes them manually. It's on my TODO list to robustify this process. OTOH, my Mac automated builds/tests are working just fine. I could produce nightly binaries from those easily enough: http://lyorn.idyll.org/ctb/pb-dev/p/python/ Just need to figure out the magic doohickey commands... will add to list. cheers, --titus -- C. Titus Brown, c...@msu.edu ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
Ned Deily n...@acm.org wrote: In article 4bc54f4f.4090...@v.loewis.de, Martin v. Lowis mar...@v.loewis.de wrote: Wasn't that problem fixed weeks ago? The installer image has been available there since several days after the release. And the link seems fine now. The inherent problem remains. There is no binary for 2.7b1, for example. The last binaries produced in the 2.7 testing process were for 2.7a2. That's true. But there wouldn't be a traditional OS X installer for 2.7b1 anyway since it turns out it is not possible to build a multi-arch installer without patching because of a bug that wasn't caught before the code cutoff since there are no OS X buildbots that test that configuration. But, at the moment, there aren't any OS X buildbots at all, are there? That *is* something that the PSF could help with. I would be happy to help with that myself I'd be happy to help where I can, too. All my automated testing of UpLib (Windows, Ubuntu, Fedora, OS X) is done on Apple servers running OS X and VirtualBox and Hudson, so I've got some experience there. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
Michael Foord fuzzy...@voidspace.org.uk wrote: Building the Mac installer requires volunteer time which I'm not sure that more hardware will fix - compiling a full build of Python for Mac OS X (with all the Python modules like Tkinter etc) requires expertise which only a few people have. That's nuts. Why isn't this expertise captured in the form of a script? A Mac OS X machine (and location to keep it) for the buildbots is a *big* need however. At least two. You want Leopard and Snow Leopard, too. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On 14/04/2010 17:36, Bill Janssen wrote: Michael Foordfuzzy...@voidspace.org.uk wrote: Building the Mac installer requires volunteer time which I'm not sure that more hardware will fix - compiling a full build of Python for Mac OS X (with all the Python modules like Tkinter etc) requires expertise which only a few people have. That's nuts. Why isn't this expertise captured in the form of a script? A Mac OS X machine (and location to keep it) for the buildbots is a *big* need however. At least two. You want Leopard and Snow Leopard, too. Well - an XServe that we can run virtualisation on would be the *ideal* solution. I think the X serves are the only machines you are *allowed* to virtualise OS X on (?). All the best, Michael Bill -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
Steve Why is it unavoidable that the Mac build will languish behind Steve others? Are we supporting MacOs or aren't we? If we are, why Steve isn't the creation of the build a part of the release process? Steve Clearly it's not a priority given that nobody has seen fit to (or Steve had time to) reply to this mail in three weeks. I'm not sure who normally creates the Mac distribution, perhaps Ronald Ousorren? It would appear that either Ronald (or whoever) has been unavailable or there was no coordination between the Mac and non-Mac folks involved in the release. I'm willing to give it a whirl (I have both a MacBook Pro and a PowerMac G5 at home - both running Max OSX 10.5.x (Leopard)) though I will almost certainly need a cheat sheet for the process. I normally treat my Macs as Unix boxes from a Python perspective so don't make framework builds. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
Steve I do think it makes us look bad to have one supported platform Steve lag the others, but it wasn't obvious to me whether hardware Steve alone was the reason. If it is, the fix should be relatively Steve simple. I can't believe it's a hardware issue. Probably half the people with laptops at the last PyCon I attended were Macs. I suspect anyone with a recent Mac running Leopard or Snow Leopard should be able to build the binary release. It's probably just a matter of knowing how. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On 14/04/2010 17:41, Michael Foord wrote: [snip...] A Mac OS X machine (and location to keep it) for the buildbots is a *big* need however. At least two. You want Leopard and Snow Leopard, too. Well - an XServe that we can run virtualisation on would be the *ideal* solution. I think the X serves are the only machines you are *allowed* to virtualise OS X on (?). An alternative that solves the problem of finding somewhere to put the machine would be to use a service like Mac Mini colocation hosting: http://www.macminicolo.net/ That could be used both for debugging OS X specific problems *and* as a buildbot. All the best, Michael All the best, Michael Bill -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On Apr 14, 2010, at 10:51 AM, s...@pobox.com wrote: Steve Why is it unavoidable that the Mac build will languish behind Steve others? Are we supporting MacOs or aren't we? If we are, why Steve isn't the creation of the build a part of the release process? Steve Clearly it's not a priority given that nobody has seen fit to (or Steve had time to) reply to this mail in three weeks. I'm not sure who normally creates the Mac distribution, perhaps Ronald Ousorren? It would appear that either Ronald (or whoever) has been unavailable or there was no coordination between the Mac and non-Mac folks involved in the release. I'm willing to give it a whirl (I have both a MacBook Pro and a PowerMac G5 at home - both running Max OSX 10.5.x (Leopard)) though I will almost certainly need a cheat sheet for the process. I normally treat my Macs as Unix boxes from a Python perspective so don't make framework builds. From the RM perspective, what I would really like to see is updates to the release.py script to check dependencies and automate as much as possible, as well as updates to PEP 101 for any process steps that can't be automated. This goes for both Windows and OS X. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
Michael Mac users definitely *do* expect installers. Building Python Michael requires, I believe, the XCode development tools to be Michael installed. XCode is free, and I suspect many people have it (I do). Michael Even then, building a full version of Python - with *all* the C Michael extensions that are part of a Python release - is not a trivial Michael task. Isn't that just a matter of having the recipe written down somewhere? Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On 14/04/2010 18:01, s...@pobox.com wrote: Michael Mac users definitely *do* expect installers. Building Python Michael requires, I believe, the XCode development tools to be Michael installed. XCode is free, and I suspect many people have it (I do). Sure - but probably not your average Python-on-Mac user. Or at least a good proportion of them, particularly newbies who we are keen to keep the experience of obtaining Python simple. First download and then install 1gigabyte of developer tools (seriously) requiring registration, then compile Python from source yourself, is not the way to go. (And yes the XCode tools are included in the OS disks - but not the latest versions, especially if you are still running Leopard.) Michael Even then, building a full version of Python - with *all* the C Michael extensions that are part of a Python release - is not a trivial Michael task. Isn't that just a matter of having the recipe written down somewhere? Yes, that would be nice. :-) Preferably a recipe that doesn't involve Macports or Fink which some of us are allergic to. Michael Skip -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] patch for review: unittest ImportError handling
On 14/04/2010 16:53, Nick Coghlan wrote: Michael Foord wrote: Changing the error message to provide more useful information, possibly including the original traceback, would certainly avoid the potential for incompatibility. I'd be interested in seeing what other folks here on python-dev think. Without looking at the details, my question is whether this can be ignored in 2.x and fixed for 3.x by setting __cause__ appropriately (i.e. by using the raise from syntax). Yes, definitely - if maintaining the exception as an AttributeError is determined to be the correct course of action for that API. Chris showed an alternative way of achieving the same effect for Python 2, but that is possibly moot given that 2.7b1 is out (unless this is an acceptable bugfix to include in b2). All the best, Michael Cheers, Nick. -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On 14 April 2010 17:04, Barry Warsaw ba...@python.org wrote: From the RM perspective, what I would really like to see is updates to the release.py script to check dependencies and automate as much as possible, as well as updates to PEP 101 for any process steps that can't be automated. This goes for both Windows and OS X. From what I recall, the PC build process is pretty much routine (I can't recall how much it's scripted, and how much it's manual, but well-documented and simple, steps). I don't know what extra is needed to build the final installer, but I'd be willing to have a go at testing the existing process and if necessary adding some automation. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
Michael Foord fuzzy...@voidspace.org.uk wrote: Isn't that just a matter of having the recipe written down somewhere? Yes, that would be nice. :-) Preferably a recipe that doesn't involve Macports or Fink which some of us are allergic to. Yes, ditto the MacPorts/Fink allergy. All we need is a script, right? The released branches should be built automatically every night anyway, just for regression testing. Perhaps we should take this up on Mac-Python? Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
What happened to the big-ass computer farm for Python which was being put together by someone at (I think) Michigan State? That sounds a lot like Snakebite (www.snakebite.org), which is still... uhhh, a work in progress ;-) We've run into an issue recently that's thwarted progress, but that'll hopefully be resolved in the next couple of weeks. And then... full steam ahead! Trent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
Bill Janssen wrote: Michael Foord fuzzy...@voidspace.org.uk wrote: Isn't that just a matter of having the recipe written down somewhere? Yes, that would be nice. :-) Preferably a recipe that doesn't involve Macports or Fink which some of us are allergic to. Yes, ditto the MacPorts/Fink allergy. All we need is a script, right? The released branches should be built automatically every night anyway, just for regression testing. Perhaps we should take this up on Mac-Python? Please do, and let me know if resources of some kind would help. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On 14/04/2010 18:49, Steve Holden wrote: Bill Janssen wrote: Michael Foordfuzzy...@voidspace.org.uk wrote: Isn't that just a matter of having the recipe written down somewhere? Yes, that would be nice. :-) Preferably a recipe that doesn't involve Macports or Fink which some of us are allergic to. Yes, ditto the MacPorts/Fink allergy. All we need is a script, right? The released branches should be built automatically every night anyway, just for regression testing. Perhaps we should take this up on Mac-Python? Please do, and let me know if resources of some kind would help. A Mac buildbot would *definitely* be useful and I know some of the Python-dev crew would like access to a Mac OS X machine for trying out fixes when none of the core Mac maintainers are around. A couple of co-located, or otherwise hosted, Mac boxes would be very useful. The obvious question is who would hold the keys (maintain the buildbot)? I don't know if Ronald has the spare capacity to do this (?). If someone will help me with the initial setup I can otherwise volunteer. All the best, Michael regards Steve -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On Wed, Apr 14, 2010 at 09:37:34AM -0700, Bill Janssen wrote: Michael Foord fuzzy...@voidspace.org.uk wrote: Isn't that just a matter of having the recipe written down somewhere? Yes, that would be nice. :-) Preferably a recipe that doesn't involve Macports or Fink which some of us are allergic to. Yes, ditto the MacPorts/Fink allergy. All we need is a script, right? The released branches should be built automatically every night anyway, just for regression testing. Please pass it along to me, when you get it working... I build python2.7 nightly on Mac OS X, but just at the command line. see: http://lyorn.idyll.org/ctb/pb-dev/p/python/ http://lyorn.idyll.org/ctb/pb-dev/p/python/show_all (the Windows build is flaky for me, so the 'show_all' shows mostly Windows builds). --titus -- C. Titus Brown, c...@msu.edu ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))
On Wednesday, April 14, 2010, at 04:47PM, Nick Coghlan ncogh...@gmail.com wrote: Martin v. Löwis wrote: Wasn't that problem fixed weeks ago? The installer image has been available there since several days after the release. And the link seems fine now. The inherent problem remains. There is no binary for 2.7b1, for example. The last binaries produced in the 2.7 testing process were for 2.7a2. That's because I haven't had time yet to actually build the installer for OSX due to lack of free time because both my professional and private lives are fully filled at the moment (which is great, but leaves very little time to hack on Python or PyObjC). I seem to recall there was some issue (aside from the current lack of a reliable OS X buildbot) Speaking of which... I have a mac-mini that could be used for a buildbot. How much work is needed to kickstart a buildbot, taking into account that I'd prefer to have a buildbot with different configure-flags that the default unix build (that is, I want to test a framework build that is a universal binary). that prevented us from regularly grabbing the head of the tree and using it to automatically build the Windows and Mac installers (to check that the installers could actually be created, preventing a repeat of the Mac situation with 2.7b1). Creating the Mac installer is easy: just run Mac/BuildScript/build-installer.py on an OSX 10.5 system where a local version of Tcl/Tk 8.4 is installed in /Library/Frameworks. The system should also not have fink or darwinports and a clean /usr/local tree to avoid contaminating the build. Ronald ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On Wed, Apr 14, 2010 at 06:52:46PM +0200, Michael Foord wrote: On 14/04/2010 18:49, Steve Holden wrote: Bill Janssen wrote: Michael Foordfuzzy...@voidspace.org.uk wrote: Isn't that just a matter of having the recipe written down somewhere? Yes, that would be nice. :-) Preferably a recipe that doesn't involve Macports or Fink which some of us are allergic to. Yes, ditto the MacPorts/Fink allergy. All we need is a script, right? The released branches should be built automatically every night anyway, just for regression testing. Perhaps we should take this up on Mac-Python? Please do, and let me know if resources of some kind would help. A Mac buildbot would *definitely* be useful and I know some of the Python-dev crew would like access to a Mac OS X machine for trying out fixes when none of the core Mac maintainers are around. A couple of co-located, or otherwise hosted, Mac boxes would be very useful. The obvious question is who would hold the keys (maintain the buildbot)? I don't know if Ronald has the spare capacity to do this (?). If someone will help me with the initial setup I can otherwise volunteer. We have some space in our machine room, and some sysadmins that like open source. I will ask them if they are willing to do physical maintenance (profs wisely aren't allowed access to the machine room). That would really be ideal... I will report back to interested people. --titus -- C. Titus Brown, c...@msu.edu ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
What happened to the big-ass computer farm for Python which was being put together by someone at (I think) Michigan State? That sounds a lot like Snakebite (www.snakebite.org), which is still... uhhh, a work in progress ;-) Actually, for those that are interested, here's a copy of the presentation I gave at the Testing in Python session at PyCon a few months ago: http://www.snakebite.org/presentations/snakebite-pycon2010-tip.pptx (Office 2007-2010) http://www.snakebite.org/presentations/snakebite-pycon2010-tip.ppt (Office 97-2003) If anything, it'll shed some light on all the unforeseen issues we've been running into since the project's inception. The presentation is a little out of date -- I spent three months earlier this year on the network and it's definitely in the most respectable state it's been in yet. Coupla' photos for those that are interested: http://snakebite.org/images/IMG_4384.JPG http://snakebite.org/images/IMG_4392.JPG http://snakebite.org/images/IMG_4393.JPG http://snakebite.org/images/IMG_4394.JPG http://snakebite.org/images/IMG_4395.JPG http://snakebite.org/images/IMG_4396.JPG http://snakebite.org/images/IMG_4401.JPG http://snakebite.org/images/IMG_4402.JPG http://snakebite.org/images/IMG_4403.JPG http://snakebite.org/images/IMG_4405.JPG http://snakebite.org/images/IMG_4410.JPG http://snakebite.org/images/IMG_4418.JPG http://snakebite.org/images/IMG_4424.JPG http://snakebite.org/images/IMG_4425.JPG We've got three racks filled to the brim with all sorts of servers: - 4xItanium 2 @ 1.5GHz, 16GB RAM, HP-UX 11iv3 - 4xItanium 2 @ 1.5GHz, 30GB RAM, RHEL 5.3 - 2xUltraSPARC III 900MHz, 8GB, Solaris 10 (file/zfs/nfs server -- 16x146GB 2Gb FC) - 2xUltraSPARC III 1.2GHz, 4GB, Solaris 10 - 2xPA-RISC 875MHz, 8GB, HP-UX 11iv1 - 4 AIX boxes w/ 2x1.5GHz, 8GB, AIX 5.1, 5.2, 5.3 6.1 - 10 dedicated VMware x86/64 boxes, ranging from dual core 8GB to 8 core monsters with 64GB - 4x667MHz AlphaServer, 8GB, Tru64 - 4x600MHz SGI Octane 300, IRIX 6.22 - and lots of other stuff. Actually, the only platform we don't have is Mac OS X. Although I've got a contact at Apple that I'll start harassing again once I'm back in East Lansing. Trent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
Michael Foord fuzzy...@voidspace.org.uk wrote: On 14/04/2010 18:49, Steve Holden wrote: Bill Janssen wrote: Michael Foordfuzzy...@voidspace.org.uk wrote: Isn't that just a matter of having the recipe written down somewhere? Yes, that would be nice. :-) Preferably a recipe that doesn't involve Macports or Fink which some of us are allergic to. Yes, ditto the MacPorts/Fink allergy. All we need is a script, right? The released branches should be built automatically every night anyway, just for regression testing. Perhaps we should take this up on Mac-Python? Please do, and let me know if resources of some kind would help. A Mac buildbot would *definitely* be useful and I know some of the Python-dev crew would like access to a Mac OS X machine for trying out fixes when none of the core Mac maintainers are around. A couple of co-located, or otherwise hosted, Mac boxes would be very useful. Yes! The obvious question is who would hold the keys (maintain the buildbot)? I don't know if Ronald has the spare capacity to do this (?). If someone will help me with the initial setup I can otherwise volunteer. Sure, I can help with that. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
Michael Foord wrote: On 14/04/2010 06:13, Ned Deily wrote: In articlehq3e52$8o...@dough.gmane.org, Steve Holdenst...@holdenweb.com wrote: Why is it unavoidable that the Mac build will languish behind others? Are we supporting MacOs or aren't we? If we are, why isn't the creation of the build a part of the release process? Clearly it's not a priority given that nobody has seen fit to (or had time to) reply to this mail in three weeks. Wasn't that problem fixed weeks ago? The installer image has been available there since several days after the release. And the link seems fine now. The problem is the process that creates a new release with a 404 link to the Mac installer with no explanation. The 2.6.5 release (as always) caused several requests to webmaster from Mac users unable to download Python - which is a further waste of volunteer time as well as a cause of frustration for users. Building the Mac installer requires volunteer time which I'm not sure that more hardware will fix - compiling a full build of Python for Mac OS X (with all the Python modules like Tkinter etc) requires expertise which only a few people have. A Mac OS X machine (and location to keep it) for the buildbots is a *big* need however. How about as a first step the release build process include a check for broken links before committing the web content for a new release? regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On 14/04/2010 19:25, Steve Holden wrote: Michael Foord wrote: On 14/04/2010 06:13, Ned Deily wrote: In articlehq3e52$8o...@dough.gmane.org, Steve Holdenst...@holdenweb.com wrote: Why is it unavoidable that the Mac build will languish behind others? Are we supporting MacOs or aren't we? If we are, why isn't the creation of the build a part of the release process? Clearly it's not a priority given that nobody has seen fit to (or had time to) reply to this mail in three weeks. Wasn't that problem fixed weeks ago? The installer image has been available there since several days after the release. And the link seems fine now. The problem is the process that creates a new release with a 404 link to the Mac installer with no explanation. The 2.6.5 release (as always) caused several requests to webmaster from Mac users unable to download Python - which is a further waste of volunteer time as well as a cause of frustration for users. Building the Mac installer requires volunteer time which I'm not sure that more hardware will fix - compiling a full build of Python for Mac OS X (with all the Python modules like Tkinter etc) requires expertise which only a few people have. A Mac OS X machine (and location to keep it) for the buildbots is a *big* need however. How about as a first step the release build process include a check for broken links before committing the web content for a new release? Yes - needed but orthogonal. :-) Michael regards Steve -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))
I seem to recall there was some issue (aside from the current lack of a reliable OS X buildbot) that prevented us from regularly grabbing the head of the tree and using it to automatically build the Windows and Mac installers (to check that the installers could actually be created, preventing a repeat of the Mac situation with 2.7b1). Am I misremembering the discussion from last time this topic came up? I only remember a similar discussion, which was about why the Windows nightly builds had been dropped. The reason was that the process was too flaky and required too much manual fixing, and that the demand for these binaries was too low. I don't recall OSX being mentioned in that discussion, though. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
Sure - but probably not your average Python-on-Mac user. Or at least a good proportion of them, particularly newbies who we are keen to keep the experience of obtaining Python simple. First download and then install 1gigabyte of developer tools (seriously) requiring registration, then compile Python from source yourself, is not the way to go. (And yes the XCode tools are included in the OS disks - but not the latest versions, especially if you are still running Leopard.) That's fine: the official binaries are (deliberately) *not* built with the latest tool chain. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))
Speaking of which... I have a mac-mini that could be used for a buildbot. How much work is needed to kickstart a buildbot, taking into account that I'd prefer to have a buildbot with different configure-flags that the default unix build (that is, I want to test a framework build that is a universal binary). The configure flags are defined on the master, so if I know what they should be, I can arrange your slave to see them. You can't then change them easily. On the slave, you need to install buildbot, and create a slave configuration; it would the be good if the slave process would somehow get restarted automatically after a system reboot (I think there are recipes for that out there). Creating the Mac installer is easy: just run Mac/BuildScript/build-installer.py on an OSX 10.5 system where a local version of Tcl/Tk 8.4 is installed in /Library/Frameworks. The system should also not have fink or darwinports and a clean /usr/local tree to avoid contaminating the build. Buildbot also supports uploading binaries to the master, which we did for the Windows builds. We could do that for OSX as well (in which case the release manager might be able to trigger a release build by just passing the right branch name in the master UI). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))
Probably fine on your personal Mac. And the build scripts can probably mask those out on their own. For a private Python installation, it doesn't actually hurt to have them on disk. The binaries may be linked with strange libraries, but it should work since the libraries themselves are also on disk. It's only that they would poison an installer - the binaries would work on no other machine. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
C. Titus Brown wrote: If Georg, Benjamin, Martin, or Ronald are interested, please just tell me (or Steve, or the PSF board, or ...) what you want and I'll work on getting it funded. For me, my company provides all the infrastructure I need (tools, bandwidth, hardware, etc). I agreed, in return, to mention that support on our group's home page: http://www.dcl.hpi.uni-potsdam.de/ Regards, Martin P.S. and yes, HPI is a company, but associated with the University of Potsdam. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))
Bill In any case, they shouldn't be needed on buildbots maintained by Bill the PSF. Sure. My question was related to humans building binary distributions though. Unless that becomes fully automated so the release manager can just push a button and have it built on and as-yet-nonexistent Mac OSX buildbot machine, somebody will have to generate that installer. Ronald says Fink, MacPorts and /usr/local are poison. If that's truly the case that's fine. It's just that it reduces the size of the potential binary installer build machines. Now that I think about it, it might not be sufficient to just hide those directories from the environment. The Python setup.py file has unconditional hard-coded references to /sw, /opt/local and /usr/local. That would probably have to change before you could use an infected machine to build the binary installer. (At the very least, searching /sw/include (for instance) could be suppressed if /sw/bin was not found in PATH. Similarly for /opt/local and /usr/local.) (ISTM the same might be true should people ever decide to once again build a Solaris installer. /opt/sfw is currently searched for Berkeley DB include files.) Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))
Martin On the slave, you need to install buildbot, and create a slave Martin configuration; it would the be good if the slave process would Martin somehow get restarted automatically after a system reboot (I Martin think there are recipes for that out there). A static IP address makes things a bit easier as well, though it's not impossible to run a buildbot using a dynamic IP address assuming you use dyndns.org or something similar to maintain the name-to-IP mapping. I ran a Mac OSX buildbot for the community buildbots for awhile but never did figure out at the time how to get it to fire up on reboot. That was a few years ago. I think today that would easily be accomplished with an @reboot crontab entry. Dunno if that was available way back then, but it's certainly supported on Mac OSX now. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
Paul Rudin wrote: Martin v. Löwis mar...@v.loewis.de writes: The major difference in the do it yourself attitude is that Mac user get a compiler for free, as part of the operating system release, whereas for Windows, they have to pay for it (leaving alone VS Express for the moment). JOOI why ignore the express versions of the MS compilers? All (I think) MS compilers are available for free in command line versions - it's the GUI tools you pay for. Primarily out of a historical perspective: I think we started providing Windows binaries primarily because some people bought the appropriate license (of Visual Studio, and Wise Installer). IMO, that's a stronger reason than mere convenience. As for available tools: I'm not sure how you would build an AMD64 release just with those tools. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
Ned Deily wrote: That *is* something that the PSF could help with. I would be happy to help with that myself, although my time to do so will be very limited for the next few weeks. The PSF still has a machine that was donated by Apple that once used to be a build slave. Unfortunately, that machine had hardware problems (or atleast appeared to have hardware problems). So if anybody would be interested into maintaining it, please let us know. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
I'd be happy to help where I can, too. All my automated testing of UpLib (Windows, Ubuntu, Fedora, OS X) is done on Apple servers running OS X and VirtualBox and Hudson, so I've got some experience there. Would you be interested in operating a build slave? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))
Making the Windows binary build process automatic and robust is challenging if you hate Windows (like I do). Martin also made the point that it's been broken forever, so people don't seem to care :). ISTR Martin just makes them manually. That's true. In particular, people had been asking that the MSI installers are code-signed, which I now also do. I wouldn't like to keep the private key for the PSF code signing certificate available to some machine that is readily accessible from the internet - so at least that part is manual, in the sense that I have to provide my password. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
Michael Foord fuzzy...@voidspace.org.uk wrote: Building the Mac installer requires volunteer time which I'm not sure that more hardware will fix - compiling a full build of Python for Mac OS X (with all the Python modules like Tkinter etc) requires expertise which only a few people have. That's nuts. Why isn't this expertise captured in the form of a script? Much of it is, but it still takes expertise to run the script. It would take even more expertise to capture the remaining pieces in the script, too, and no living person has that much expertise to write the script (perhaps there are one or two people, and they don't have the time). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
How about as a first step the release build process include a check for broken links before committing the web content for a new release? You'd have to convince the release manager to add a step to the release process. Given that the release process has already too many steps, he is probably skeptical wrt. such a proposal. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
From what I recall, the PC build process is pretty much routine (I can't recall how much it's scripted, and how much it's manual, but well-documented and simple, steps). I don't know what extra is needed to build the final installer, but I'd be willing to have a go at testing the existing process and if necessary adding some automation. I do *a lot* of manual steps, because I didn't have time to script it all. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))
(ISTM the same might be true should people ever decide to once again build a Solaris installer. /opt/sfw is currently searched for Berkeley DB include files.) And rightly so (likewise for Fink). Primarily, the script is there to help people installing Python; packaging Python can be more difficult. I guess ActiveState has solved the problem (probably by not populating /opt/sfw on the Solaris machine that builds ActivePython). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On 14/04/2010 20:21, Martin v. Löwis wrote: Mac users definitely *do* expect installers. Building Python requires, I believe, the XCode development tools to be installed. Even then, building a full version of Python - with *all* the C extensions that are part of a Python release - is not a trivial task. The same is true for any other operating system, though: you need to install the compiler tool chain (sometimes, you need to buy it first), and compiling Python with all extensions is not a trivial task. Right - but we were discussing this in the context of barrier to entry, particularly to new users. We don't impose this requirement for Windows users though - we provide binary installers. I *know* we're a volunteer organisation (etc), but it is good for us to be aware of our process weaknesses without excusing ourselves. Unfortunately the Mac installer build script doesn't seem to run at all on Mac OS X 10.6 (at least not on my machine), but hopefully the situation is clarified so that one of us who does still have Mac OS X 10.5 will be able to build the installer in a timely manner for the next release should Ronald be too busy. All the best, Michael Regards, Martin -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))
On 14 April 2010 20:02, s...@pobox.com wrote: I ran a Mac OSX buildbot for the community buildbots for awhile but never did figure out at the time how to get it to fire up on reboot. That was a few years ago. I think today that would easily be accomplished with an @reboot crontab entry. Dunno if that was available way back then, but it's certainly supported on Mac OSX now. launchd might be a better bet - http://bit.ly/ahwvTk. -- Cheers, Simon B. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
Right - but we were discussing this in the context of barrier to entry, particularly to new users. We don't impose this requirement for Windows users though - we provide binary installers. I *know* we're a volunteer organisation (etc), but it is good for us to be aware of our process weaknesses without excusing ourselves. I think nobody here is questioning that it is desirable to have OSX binaries. And I readily admit that this is a weakness. Unfortunately the Mac installer build script doesn't seem to run at all on Mac OS X 10.6 (at least not on my machine), but hopefully the situation is clarified so that one of us who does still have Mac OS X 10.5 will be able to build the installer in a timely manner for the next release should Ronald be too busy. I'm not sure whether 10.5 would be sufficient - it may be that you need to go back to 10.4 (*). Unfortunately, Apple manages to break compatibility and portability with every release, which makes this particular build task s tricky. You have to make all kinds of decisions and compromises where are really difficult to keep track of. Regards, Martin (*) I know that this is the version I had to go back to when I created OSX binaries for 2.5.x. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On 14/04/2010 21:37, Martin v. Löwis wrote: [snip...] Unfortunately the Mac installer build script doesn't seem to run at all on Mac OS X 10.6 (at least not on my machine), but hopefully the situation is clarified so that one of us who does still have Mac OS X 10.5 will be able to build the installer in a timely manner for the next release should Ronald be too busy. I'm not sure whether 10.5 would be sufficient - it may be that you need to go back to 10.4 (*). Unfortunately, Apple manages to break compatibility and portability with every release, which makes this particular build task s tricky. You have to make all kinds of decisions and compromises where are really difficult to keep track of. In an earlier email Ronald said: Creating the Mac installer is easy: just run Mac/BuildScript/build-installer.py on an OSX 10.5 system where a local version of Tcl/Tk 8.4 is installed in /Library/Frameworks. The system should also not have fink or darwinports and a clean /usr/local tree to avoid contaminating the build. I can't verify that this is correct, I can verify it that the build-installer script doesn't appear to work under 10.6. Michael Regards, Martin (*) I know that this is the version I had to go back to when I created OSX binaries for 2.5.x. -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))
On Apr 14, 2010, at 3:30 PM, Simon Brunning wrote: On 14 April 2010 20:02, s...@pobox.com wrote: I ran a Mac OSX buildbot for the community buildbots for awhile but never did figure out at the time how to get it to fire up on reboot. That was a few years ago. I think today that would easily be accomplished with an @reboot crontab entry. Dunno if that was available way back then, but it's certainly supported on Mac OSX now. launchd might be a better bet - http://bit.ly/ahwvTk. Exactly, launchd is the program intended for such use. A small nitpick at that property list shown in the linked example: It should be Apple now instead of Apple Computer. They officially changed the name and all the new developer documentation shows the property lists with -//Apple/DTD ... :-) Regards, Zvezdan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))
On 14 Apr, 2010, at 19:41, s...@pobox.com wrote: Ronald Creating the Mac installer is easy: just run Ronald Mac/BuildScript/build-installer.py on an OSX 10.5 system where a Ronald local version of Tcl/Tk 8.4 is installed in Ronald /Library/Frameworks. The system should also not have fink or Ronald darwinports and a clean /usr/local tree to avoid contaminating Ronald the build. For those of us who live in an X11 world and use tools which Apple doesn't provide, like it or not, Fink or MacPorts are often a practical necessity. Would it be sufficient to modify the environment so that /sw, /opt/local and /usr/local don't appear in any paths when the script is run? On my laptop (MacPorts installed, not Fink) I see that MANPATH, PATH and INFOPATH are currently polluted with /opt/local. MANPATH and PATH contain /usr/local. /usr/local/lib and /usr/local/include must be empty, or at least not contain anything that might be used by the python build. AFAIK it is practically impossible[1] to tell the compiler to exclude /usr/local from its search paths. Fink and Macports must be disabled because Python's setup.py actively looks in those directory for dependencies (such as for BerkelyDB). I wouldn't mind having a configure switch that disables looking in the default Fink and Macports trees, but don't have time to work on that myself. BTW. Excluding these locations is only needed when building the official installer, you can obviously just keep them around when you build and use Python locally. I tend to move /usr/local aside when I build the installer and move it back afterwards, and have used an mostly empty virtual machine for the last couple of releases. Ronald [1] that is, the only way I've found it to tell gcc not to use any search paths at all and manually specify all search paths, including compiler-specific directories. Skip smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On Apr 14, 2010, at 3:37 PM, Martin v. Löwis wrote: I'm not sure whether 10.5 would be sufficient - it may be that you need to go back to 10.4 (*). I think you just need to supply to configure MACOSX_DEPLOYMENT_TARGET=10.4 and have the appropriate SDK installed with Xcode. I believe it is installed by default with Xcode on Leopard (10.5), but with Xcode on Snow Leopard (10.6) the 10.4 SDK is an optional install. Unfortunately, Apple manages to break compatibility and portability with every release, which makes this particular build task s tricky. You have to make all kinds of decisions and compromises where are really difficult to keep track of. Hmm. Apple provided compatibility SDK and documented it. The only compromise I see in this build process right now is that we are building a Panther (10.3) compatible installer, while Mac OS X is a certified UNIX starting with 10.5. So, we are deliberately using obsolete model to provide backward compatibility. However, I'm fine with that for the installer. Power users can compile their own build optimized for their platform. Regards, Zvezdan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On Wed, Apr 14, 2010 at 14:03, Martin v. Löwis mar...@v.loewis.de wrote: Paul Rudin wrote: Martin v. Löwis mar...@v.loewis.de writes: The major difference in the do it yourself attitude is that Mac user get a compiler for free, as part of the operating system release, whereas for Windows, they have to pay for it (leaving alone VS Express for the moment). JOOI why ignore the express versions of the MS compilers? All (I think) MS compilers are available for free in command line versions - it's the GUI tools you pay for. Primarily out of a historical perspective: I think we started providing Windows binaries primarily because some people bought the appropriate license (of Visual Studio, and Wise Installer). IMO, that's a stronger reason than mere convenience. As for available tools: I'm not sure how you would build an AMD64 release just with those tools. Regards, Martin Outside of hacking the registry and various config files, 64-bit builds can't be done with the express versions of Visual Studio, and I wouldn't be comfortable shipping a product built in that way. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))
On 14 Apr, 2010, at 20:46, Martin v. Löwis wrote: Speaking of which... I have a mac-mini that could be used for a buildbot. How much work is needed to kickstart a buildbot, taking into account that I'd prefer to have a buildbot with different configure-flags that the default unix build (that is, I want to test a framework build that is a universal binary). The configure flags are defined on the master, so if I know what they should be, I can arrange your slave to see them. You can't then change them easily. That's fine. I'll first create a stable environment for performing builds/tests and contact you when I'm ready to be added to the buildbot farm. On the slave, you need to install buildbot, and create a slave configuration; it would the be good if the slave process would somehow get restarted automatically after a system reboot (I think there are recipes for that out there). That should be easy enough to arange. The buildbot manual mentions an @reboot crontab entry, but a launchd item should be easy enough and is slightly cleaner. Creating the Mac installer is easy: just run Mac/BuildScript/build-installer.py on an OSX 10.5 system where a local version of Tcl/Tk 8.4 is installed in /Library/Frameworks. The system should also not have fink or darwinports and a clean /usr/local tree to avoid contaminating the build. Buildbot also supports uploading binaries to the master, which we did for the Windows builds. We could do that for OSX as well (in which case the release manager might be able to trigger a release build by just passing the right branch name in the master UI). How would that work? Creation of the OSX installer is not integrated in the regular Makefiles but is a separate script. A slightly problematic issue is that the machine I want to use for the buildbot is running OSX 10.6 and creating the binary installer doesn't work on 10.6 yet, but that should be easy enough to fix when I look into it. Ronald Regards, Martin smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))
I ran a Mac OSX buildbot for the community buildbots for awhile but never did figure out at the time how to get it to fire up on reboot. Â That was a few years ago. Â I think today that would easily be accomplished with an @reboot crontab entry. Â Dunno if that was available way back then, but it's certainly supported on Mac OSX now. Simon launchd might be a better bet - http://bit.ly/ahwvTk. Sure, but it's Mac-specific. For someone like myself who moves between different platforms I generally try to use tools which work across those platforms to the extent that I can. While @reboot is not universally available (Solaris doesn't support it as far as I can tell) it is still more common where I operate than launchd. Not to mention which I have to horse around with XML for config files which I completely detest for that purpose. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] patch for review: __import__ documentation
On Tue, Apr 13, 2010 at 20:54, Chris Jerdonek chris.jerdo...@gmail.comwrote: Here is another patch for review: http://bugs.python.org/issue8370 This is a trivial fix to the 2.6 and 2.7 documentation. There is no need to email python-dev about individual patches just to get them looked at. There is a mailing list that we all subscribe to that send an email on all new issues and another one on every change to any issue. You should only email python-dev if a patch you wrote has been sitting around for a very long time and is not being actively looked at or you think it should hold up a release. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))
How would that work? Creation of the OSX installer is not integrated in the regular Makefiles but is a separate script. Again by setting up another builder (and assigning it to either the same or a different slave). Instead of the regular configure/make/make test/make clean builder, this one would configure/run build script/upload/clean. Essentially, a builder will invoke arbitrary shell scripts on the slave, which will (slavishly :-) perform them. So make sure this can run under an untrusted account; anybody with control over the master can get access to all slaves (but we do keep access to the master very tightly restricted). In addition, all committers basically have control over all slaves (by committing stuff into the makefile); this is, of course, monitored through the checkins list. I recommend we look at daily installers after the regular slave is set up. A slightly problematic issue is that the machine I want to use for the buildbot is running OSX 10.6 and creating the binary installer doesn't work on 10.6 yet, but that should be easy enough to fix when I look into it. So we should definitely take one step at a time. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
I think you just need to supply to configure MACOSX_DEPLOYMENT_TARGET=10.4 and have the appropriate SDK installed with Xcode. Wouldn't that break 10.3 compatibility (seel below)? Unfortunately, Apple manages to break compatibility and portability with every release, which makes this particular build task s tricky. You have to make all kinds of decisions and compromises where are really difficult to keep track of. Hmm. Apple provided compatibility SDK and documented it. The only compromise I see in this build process right now is that we are building a Panther (10.3) compatible installer, while Mac OS X is a certified UNIX starting with 10.5. I think there are more issues. People want a fat binary that supports AMD64 along with x86, yet building such a binary requires an SDK that won't support PPC anymore - right? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] patch for review: __import__ documentation
On Wed, Apr 14, 2010 at 1:32 PM, Brett Cannon br...@python.org wrote: There is no need to email python-dev about individual patches just to get them looked at. There is a mailing list that we all subscribe to that send an email on all new issues and another one on every change to any issue. You should only email python-dev if a patch you wrote has been sitting around for a very long time and is not being actively looked at or you think it should hold up a release. Sorry, I had received somewhat different guidance on tracker-discuss: http://mail.python.org/pipermail/tracker-discuss/2010-April/002482.html http://mail.python.org/pipermail/tracker-discuss/2010-April/002483.html http://mail.python.org/pipermail/tracker-discuss/2010-April/002484.html Otherwise, I would not have bothered to e-mail the list. I will be more conservative about posting to python-dev in the future. --Chris ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On Wed, 14 Apr 2010 14:06:44 -0400, Eric Smith e...@trueblade.com wrote: Steve Holden st...@holdenweb.com wrote: I spent some considerable effort last year ensuring the developer community was well-supplied with MS developer licenses that give access to any necessary tools. Was I wasting my time? In my case it was not a waste of time. I use MSDN for dev and testing. Just not for release building. Ditto. Without the license I wouldn't have a Windows machine that I could run tests on at all (I run the OS in KVM instances). -- R. David Murray www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
Martin v. Löwis mar...@v.loewis.de wrote: I'd be happy to help where I can, too. All my automated testing of UpLib (Windows, Ubuntu, Fedora, OS X) is done on Apple servers running OS X and VirtualBox and Hudson, so I've got some experience there. Would you be interested in operating a build slave? I could help to maintain some OS X buildbots located somewhere, sure. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
Martin v. Löwis mar...@v.loewis.de wrote: Michael Foord fuzzy...@voidspace.org.uk wrote: Building the Mac installer requires volunteer time which I'm not sure that more hardware will fix - compiling a full build of Python for Mac OS X (with all the Python modules like Tkinter etc) requires expertise which only a few people have. That's nuts. Why isn't this expertise captured in the form of a script? Much of it is, but it still takes expertise to run the script. Apparently not, according to Ronald's recent mail. I'd be happy to help with whatever remaining capture is necessary for OS X -- not automating this kind of thing is nuts. My buildbots build UpLib, and most of its optional packages (including ghostscript, xpdf, libtiff, openssl, t1lib, Lucene, PyLucene, etc.) from source every night, and whenever I do an UpLib check-in. On Linux and OS X, right now -- I'm working on Windows right now. It would take even more expertise to capture the remaining pieces in the script, too, and no living person has that much expertise to write the script (perhaps there are one or two people, and they don't have the time). Well, God forbid they should ever be hit by a bus! This kind of thing needs to be written down. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] patch for review: __import__ documentation
On Wed, Apr 14, 2010 at 13:41, Chris Jerdonek chris.jerdo...@gmail.comwrote: On Wed, Apr 14, 2010 at 1:32 PM, Brett Cannon br...@python.org wrote: There is no need to email python-dev about individual patches just to get them looked at. There is a mailing list that we all subscribe to that send an email on all new issues and another one on every change to any issue. You should only email python-dev if a patch you wrote has been sitting around for a very long time and is not being actively looked at or you think it should hold up a release. Sorry, I had received somewhat different guidance on tracker-discuss: http://mail.python.org/pipermail/tracker-discuss/2010-April/002482.html http://mail.python.org/pipermail/tracker-discuss/2010-April/002483.html http://mail.python.org/pipermail/tracker-discuss/2010-April/002484.html Otherwise, I would not have bothered to e-mail the list. I see the confusion. I think Martin meant more about open issues that required discussion, not simply issues that had a patch ready to go. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
Michael Foord wrote: Building Python requires, I believe, the XCode development tools to be installed. Even then, building a full version of Python - with *all* the C extensions that are part of a Python release - is not a trivial task. What's non-trivial about it? I usually find that the normal ./configure; make; make install sequence works fine without any further intervention. If you want a framework installation you have to read the README and use a couple of extra options, but it still works very smoothly. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On 14/04/2010 23:32, Greg Ewing wrote: Michael Foord wrote: Building Python requires, I believe, the XCode development tools to be installed. Even then, building a full version of Python - with *all* the C extensions that are part of a Python release - is not a trivial task. What's non-trivial about it? I usually find that the normal ./configure; make; make install sequence works fine without any further intervention. If you want a framework installation you have to read the README and use a couple of extra options, but it still works very smoothly. A build on my machine produces output similar to: Python build finished, but the necessary bits to build these modules were not found: _bsddb dl gdbm imageoplinuxaudiodev ossaudiodev readline spwd sunaudiodev To find the necessary bits, look in setup.py in detect_modules() for the module's name. Failed to build these modules: _tkinter Obviously many of those are not meant to be built and I usually build Python for running the test suite - so I don't care about not having Tkinter. A new user of Python would most certainly care about not having Tkinter. Michael -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
Paul Moore p.f.mo...@gmail.com writes: On 14 April 2010 07:37, Paul Rudin p...@rudin.co.uk wrote: Martin v. Löwis mar...@v.loewis.de writes: The major difference in the do it yourself attitude is that Mac user get a compiler for free, as part of the operating system release, whereas for Windows, they have to pay for it (leaving alone VS Express for the moment). JOOI why ignore the express versions of the MS compilers? All (I think) MS compilers are available for free in command line versions - it's the GUI tools you pay for. I believe that the express editions don't include some of the advanced optimisations (profile guided optimisation rings a bell) which are used to build the official binaries. So if the binaries were built using Express Edition, they would be somewhat slower. That is just my recollection, however - it may be out of date or wrong. Paul. I could be wrong too. However I think I had two things confused (it's been a while since I've done any windows development). There are two different suites of free compilers from MS. There's the windows sdk, which includes a command line toolchain and the express edition of VS which (essentially) is a cut down version of the commercial version of VS. Some info about the windows sdk versions is here http://msdn.microsoft.com/en-us/windows/dd146047.aspx and about versions - including Express - here (at least for VC++) http://msdn.microsoft.com/en-us/library/hs24szh9%28VS.90%29.aspx although that's a little old. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))
Martin v. Löwis wrote: I seem to recall there was some issue (aside from the current lack of a reliable OS X buildbot) that prevented us from regularly grabbing the head of the tree and using it to automatically build the Windows and Mac installers (to check that the installers could actually be created, preventing a repeat of the Mac situation with 2.7b1). Am I misremembering the discussion from last time this topic came up? I only remember a similar discussion, which was about why the Windows nightly builds had been dropped. The reason was that the process was too flaky and required too much manual fixing, and that the demand for these binaries was too low. I don't recall OSX being mentioned in that discussion, though. Yep, that sounds like the discussion I was thinking of. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
Martin v. Löwis wrote: The same is true for any other operating system, though: you need to install the compiler tool chain (sometimes, you need to buy it first), and compiling Python with all extensions is not a trivial task. Even on Linux, it takes a bit of fiddling. I finally remembered to write the steps down for Kubuntu when I set up my current machine (you need to apt-get half a dozen or so additional dev packages): http://boredomandlaziness.blogspot.com/2010/01/kubuntu-dev-packages-to-build-python.html Take away the convenience of apt-get and add installing the compiler and installer toolchains and you've got a fair amount of setup time on your hands (and lots of things that can go wrong). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On 14 April 2010 18:36, Steve Holden st...@holdenweb.com wrote: I spent some considerable effort last year ensuring the developer community was well-supplied with MS developer licenses that give access to any necessary tools. Was I wasting my time? Definitely not - my offer is at least in part based on the fact that I have the full tools as a result and so can do (hopefully) useful work on assisting with any necessary build process improvements. My comment was in response to the question why are we ignoring the express editions? If having the full versions wasn't better than having the free ones, the developer licenses would be of less benefit (and that isn't the case, as I say). Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On Apr 14, 2010, at 4:40 PM, Martin v. Löwis wrote: I think you just need to supply to configure MACOSX_DEPLOYMENT_TARGET=10.4 and have the appropriate SDK installed with Xcode. Wouldn't that break 10.3 compatibility (seel below)? I was replying to your point about 10.4 build. Naturally, if you want a 10.3 build you'd pass 10.3 as the target and would have to have appropriate Xcode SDK installed. Unfortunately, Apple manages to break compatibility and portability with every release, which makes this particular build task s tricky. You have to make all kinds of decisions and compromises where are really difficult to keep track of. Hmm. Apple provided compatibility SDK and documented it. The only compromise I see in this build process right now is that we are building a Panther (10.3) compatible installer, while Mac OS X is a certified UNIX starting with 10.5. I think there are more issues. People want a fat binary that supports AMD64 along with x86, yet building such a binary requires an SDK that won't support PPC anymore - right? Yes. x86_64, i386, and ppc are supported even in the Xcode supplied with the latest Mac OS X 10.6. Only ppc64 is not. So, ppc is not an issue. The problem is that enforcing backward compatibility with 10.3 and 10.4 makes 64-bit Intel architecture not feasible. You are right, it is a compromise. We are making more users happy by providing a 32-bit installer for a wider range of OS releases. However, if we want a more modern certified UNIX, 64-bit installer, then we'll have to draw a line and stop supporting older OS releases. Just as we stop supporting older releases of Python. Regards, Zvezdan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3147 ready for pronouncement and merging
Brett Cannon wrote: And just a quick suggestion: can we standardize what imp.source_to_path() and friend are supposed to return if the interpreter doesn't support bytecode? I will probably have to rely on that for something so it would be best to say now whether it should be None or raise an exception so there is no divergence on this between VMs. Returning None sounds like the most straightforward option. __cached__ = None will just mean for whatever reason, we have no cached filename for this file. It may be the cached file doesn't exist, or the interpreter simply wasn't in a position to figure it out in a user visible way. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))
s...@pobox.com wrote: Now that I think about it, it might not be sufficient to just hide those directories from the environment. The Python setup.py file has unconditional hard-coded references to /sw, /opt/local and /usr/local. That I added that to my virus scanner: check any setup.py files for /sw. I autopatch a couple of the commopn ones to get rid of it. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3147 ready for pronouncement and merging
On Apr 15, 2010, at 08:33 AM, Nick Coghlan wrote: Brett Cannon wrote: And just a quick suggestion: can we standardize what imp.source_to_path() and friend are supposed to return if the interpreter doesn't support bytecode? I will probably have to rely on that for something so it would be best to say now whether it should be None or raise an exception so there is no divergence on this between VMs. Returning None sounds like the most straightforward option. __cached__ = None will just mean for whatever reason, we have no cached filename for this file. It may be the cached file doesn't exist, or the interpreter simply wasn't in a position to figure it out in a user visible way. I completely agree. The PEP already leaves __cached__ up to the implementation, but I'll update it to be clear that None is an acceptable return value from imp.cached_from_source() (which is the one I think you mean), and also what __cached__=None means. Thanks Brett and Nick. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))
Bill Janssen writes: Fink or MacPorts are often a practical necessity. Fink is deadly, MacPorts much more benign, in my experience. Which is several years out-of-date, before I realized I didn't need either one of them, and before the UNIX community started adding configure patches to support OS X builds more widely. Perhaps they've improved. FWIW, I use MacPorts heavily, and it works fine for the most recent release of Mac OS X which has been out for at least 6 months. Bug fixes for Snow Leopard in MacPorts are typically a matter of a handful of hours, but many port maintainers don't have full-time access to Leopard, and few will do more than pay lip service and help install a patch if you have problems with Tiger. IOW, the previous release always has occasional glitches, and the second previous release is a nightmare. MacPorts is fine if you don't mind occasionally messing with it and don't need to deal with Mac OS versions getting even slightly long in the tooth. In any case, they shouldn't be needed on buildbots maintained by the PSF. They should be avoided, as many users won't have them. MacPorts and presumably Fink have their own testing process, and the quality of /opt/local/lib varies quite a bit. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
Greg Ewing wrote: Michael Foord wrote: Building Python requires, I believe, the XCode development tools to be installed. Even then, building a full version of Python - with *all* the C extensions that are part of a Python release - is not a trivial task. What's non-trivial about it? Building a DMG file, in a way that the output will actually work on most other systems. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
