In article <4bc54f4f.4090...@v.loewis.de>,
"Martin v. Lowis" 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
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 da
On 14/04/2010 06:13, Ned Deily wrote:
In article,
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 giv
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.
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
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
aforemen
-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 rele
On Wed, Apr 14, 2010 at 2:07 AM, Michael Foord
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 propag
On 14 April 2010 07:37, Paul Rudin wrote:
> "Martin v. Löwis" 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 t
On 14/04/2010 12:54, Chris Jerdonek wrote:
On Wed, Apr 14, 2010 at 2:07 AM, Michael Foord
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
On Wed, Apr 14, 2010 at 4:12 AM, Michael Foord
wrote:
> On 14/04/2010 12:54, Chris Jerdonek wrote:
>>
>> On Wed, Apr 14, 2010 at 2:07 AM, Michael Foord
>> wrote:
>>
>>>
>>> I'm still not convinced that this isn't a backwards incompatible change -
>>> up
>>> until now, however horrible it may be,
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
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
__
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
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 unabl
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.
Yo
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 are
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 lin
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.
> >>
> >
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 diff
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 compare
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'
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 obvio
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
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
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
Ned Deily wrote:
> In article <4bc54f4f.4090...@v.loewis.de>,
> "Martin v. Lowis" 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 re
Michael Foord 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 t
On 14/04/2010 17:36, Bill Janssen wrote:
Michael Foord 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
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> 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 pe
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 s
Ned> ... since there are no OS X buildbots that test that configuration.
Ned> But, at the moment, there aren't any OS X buildbots at all, are
Ned> there? That *is* something that the PSF could help with
What happened to the big-ass computer farm for Python which was being put
tog
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 i
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* th
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 probabl
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 thi
On 14 April 2010 17:04, Barry Warsaw 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
Michael Foord 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, r
> 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'l
Bill Janssen wrote:
> Michael Foord 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.
On 14/04/2010 18:49, Steve Holden wrote:
Bill Janssen wrote:
Michael Foord 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
On Wed, Apr 14, 2010 at 09:37:34AM -0700, Bill Janssen wrote:
> Michael Foord 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 all
On Wednesday, April 14, 2010, at 04:47PM, "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
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 Foord wrote:
>>>
>>>
> Isn't that just a matter of having the recipe written down somewhere?
>
>
Yes, that would be n
> > 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 t
Michael Foord wrote:
> On 14/04/2010 18:49, Steve Holden wrote:
> > Bill Janssen wrote:
> >
> >> Michael Foord wrote:
> >>
> >>
> Isn't that just a matter of having the recipe written down somewhere?
>
>
> >>> Yes, that would be nice. :-) Preferably a recipe th
Michael Foord wrote:
> On 14/04/2010 06:13, Ned Deily wrote:
>> In article,
>> 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
On 14/04/2010 19:25, Steve Holden wrote:
Michael Foord wrote:
On 14/04/2010 06:13, Ned Deily wrote:
In article,
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 crea
Paul Moore wrote:
> On 14 April 2010 07:37, Paul Rudin wrote:
>> "Martin v. Löwis" 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
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
On Apr 14, 2010, at 01:36 PM, Steve Holden 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?
At the time I didn't care because I had no access to anythi
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
>
On Wed, Apr 14, 2010 at 12:36, Steve Holden wrote:
> Paul Moore wrote:
> > On 14 April 2010 07:37, Paul Rudin wrote:
> >> "Martin v. Löwis" 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 re
In my case it was not a waste of time. I use MSDN for dev and testing. Just not
for release building.
"Steve Holden" wrote:
>Paul Moore wrote:
>> On 14 April 2010 07:37, Paul Rudin wrote:
>>> "Martin v. Löwis" writes:
>>>
The major difference in the "do it yourself" attitude is that Mac
On Apr 14, 2010, at 09:52 AM, 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
> 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 othe
> 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,
> I personally think the Mac is pretty important, as one of the big three
> consumer operating systems...
[...]
> I don't know what to do about motivation but if there are barriers that
> we can lower, please let me know.
For example, you could volunteer to produce OSX binaries in a timely
manner
> 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,
> preven
> 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 com
> 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
> 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 o
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 ret
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-nonexiste
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 addre
Paul Rudin wrote:
> "Martin v. Löwis" 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 wh
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, tha
> 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
_
> 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 askin
> Michael Foord 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.
> 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
>>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
> (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 di
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 triv
On 14 April 2010 20:02, 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
> 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 w
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 i
On Apr 14, 2010, at 3:30 PM, Simon Brunning wrote:
> On 14 April 2010 20:02, 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 a
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
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 belie
On Wed, Apr 14, 2010 at 14:03, "Martin v. Löwis" wrote:
> Paul Rudin wrote:
> > "Martin v. Löwis" 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
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 buil
>> 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
>
On Tue, Apr 13, 2010 at 20:54, Chris Jerdonek wrote:
> 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
> 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
> 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
On Wed, Apr 14, 2010 at 1:32 PM, Brett Cannon 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
On Wed, 14 Apr 2010 14:06:44 -0400, Eric Smith wrote:
> "Steve Holden" 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
Martin v. Löwis 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?
Martin v. Löwis wrote:
> > Michael Foord 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
On Wed, Apr 14, 2010 at 13:41, Chris Jerdonek wrote:
> On Wed, Apr 14, 2010 at 1:32 PM, Brett Cannon 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
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 nor
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-trivi
Paul Moore writes:
> On 14 April 2010 07:37, Paul Rudin wrote:
>> "Martin v. Löwis" 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 (leavi
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 ac
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 t
On 14 April 2010 18:36, Steve Holden 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 fac
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 bui
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
1 - 100 of 106 matches
Mail list logo
