Re: [Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))

[David Bolen]

Ronald Oussoren  writes:

> 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).

Sort of picking this message to enter the thread ...

Interestingly enough, I had made an offer to Martin to host an OSX
build slave last week (before this thread), since I had a Mini whose
disk crashed and would be reasonably free after I rebuilt it, and I
had noticed there were no longer any OSX build slaves around.

It's online now, though it certainly need not be the only one.
There's not much to setting up a build slave - just easy_install
buildbot on top of a basic Python install (you'll need Twisted), use
the "build-slave" command to create a tree, edit the files in "info",
and "buildbot start " to get it started.  Of course,
there's some overhead to monitoring things over time.

My new slave is a Tiger box, since that's what I still need for my own
application builds. So it won't help with building/testing x64 builds.

Per the "startup on reboot" part of the thread, I typically use the
LaunchAgents setup on my Macs for that purpose, although to be honest,
not many of my build slaves start automatically anyway, as the boxes
don't tend to get restarted other than manually.

In the first builds, I have noticed that the build master seems to
execute the builds as a Unix system, so isn't building with the
universalsdk option or as a framework, though the latter would
probably need a bit of glue to make the framework available just
locally to the buildbot process.

On Windows, the buildbot tasks use scripts that keep the third party
stuff in the buildbot branch tree itself.  I wonder if perhaps with a
little TLC, we could come up with some Mac-specific buildbot scripts
to better have an OSX build slave mimic the final build process.  It
might be as simple as using build-installer with a specified directory
within the build tree, though utilitizing the built framework for the
tests probably needs some support.  The build master could then be
set to execute those scripts (much as it does on Windows) rather than
the stock Unix approach.

I anticipate some tuning to do with respect to external libraries.
Rather than use system libraries or my own (or finks or MacPorts)
version of libraries, I suspect it would be better to download the
same releases of the third party stuff that the installer script
downloads and install them locally for normal buildbot builds, to best
match what would be packaged up with a final binary.  Of course, if
so, then there's the question of keeping the buildbot environment up
to date with the installer script.

As I believe Martin mentioned elsewhere in the thread, he used to have
my Windows slave generate nightly MSI builds and upload them, but the
process became fragile over time, and didn't seem to be missed when we
discontinued them.  But something similar could probably be worked out
for building nightly DMGs for OSX if it were deemed useful.

> 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.

Yes, I've successfully used the script to create a DMG of the latest
2.7 out of trunk, and at least the basic sniff test (install it
locally, run a few things) seems fine.  Did run into one quirk where
if you have already built Python within the tree you run the script
from, it doesn't rebuild everything beneath /tmp/_py/_bld - such as
the pgen stuff.  So you want a clean source tree too.

To the extent that the output (DMG) of the build-installer script is
what is currently needed for OSX, I can generate one if it is still
needed, though I can't promise much beyond just executing the script.
The new build slave can also be made available for RMs (or whomever)
to generate the DMG when needed if that might be helpful.  Though
there should probably be some basic installation test on other systems
prior to publishing any such generated files.

-- David

___
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] OS information, tags

[anatoly techtonik]

On Tue, Apr 13, 2010 at 3:54 PM, Nick Coghlan  wrote:
>
>>>            I am surprised to see that the bug-tracker
>>> doesn't have an OS classifier or ability to add
>>> tags ? Since a number of issues reported seem to

Just to remind about my +1 for user editable tags.

>> There is one. In the Components you can do a multiple select and it
>> has Macintosh , Windows as options.
>
> I think that setup dates from the Sourceforge days when we didn't have
> keywords or the ability to add our own fields. Would it make sense to
> put a request on the metatracker to convert these to keywords now that
> they're available?

Keywords are not currently editable by users.

> Or even a separate OS field with "Windows, Mac OS X,
> Linux, *BSD, Other" as the options?

It is not uncommon when code written on Unix can affect both MacOS and
Windows, so you need to be able to select both.

> While there is some Windows and Mac specific code, treating them as
> separate components seems fairly unintuitive.

-- 
anatoly t.
___
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))

[David Cournapeau]

On Thu, Apr 15, 2010 at 3:54 AM,   wrote:
>
>    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.

Actually, you can just use a chroot "jail" to build the binary - I use
this process to build the official numpy/scipy binaries, it works very
well whatever crap there is on my laptop otherwise.

cheers,

David
___
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]

In article <4bc697d2.4020...@v.loewis.de>,
 "Martin v. Lowis"  wrote:
> 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.

As Ronald pointed out, the installer build script does all of the dirty 
work of building the install disk image (the .dmg file), including 
downloading and building necessary third-party libraries.   What isn't 
automatically checked at the moment is that the third-party Tk framework 
is in place during the build and that there isn't contamination from the 
build user's environment.  There is a patch in Issue5651 to do much of 
that.  It doesn't currently try to handle the possibility of MacPorts 
(/opt/local) and Fink (/sw) contamination.  I believe that issue should 
be addressed by the resolution of Issue7713.

Keep in mind that Python on OS X supports the standard OS X 
multi-architecture (Intel vs PPC and/or 32-bit vs 64-bit executables in 
the same file) and multi-version features (the current installer builds 
are fully supported on 10.6, 10.5, and 10.4 and "best-effort" supported 
on 10.3 as well although building is not supported on 10.3) as well as 
"Unix" shared library vs OS X framework shared library configurations.  
That leads to a rather imposing matrix of potential build systems vs 
potential target systems.  For the most part, Apple provides excellent 
upward compatibility; downward is somewhat trickier.   OS X 10.6 (Snow 
Leopard) has complicated matters by the change to preferring 64-bit 
building and executing where possible.  For python builds, some build 
configurations that worked by default under 10.5 and earlier no longer 
do so on 10.6, primarily due to standard library modules that depend on 
APIs, in many cases deprecated ones, that are only available in 32-bit 
versions.  The old Macintosh modules comprise the biggest group of these 
and, while they have been removed in 3.x, they still remain in 2.x.  But 
there are some others as well, which explain most of the build issues 
Michael reported.  There are also newer versions of some open source 
libraries in 10.6 which cause problems for multi-version builds: 
openssl, for one, and Apple's 64-bit version of Tk 8.5.

None of these problems are insolvable but with the very limited 
resources (i.e. people time) we've had for working on these issues, and 
when there have been so many other more critical problems, it has been 
easier up to now to stick with building on 10.5 (or even on 10.4 which I 
test build occasionally).  I think the single most important thing that 
can be done to help right now is to get a robust system of OS X 
buildbots going so that many of the critical problems can be detected up 
front rather than when one of us gets around to building and install 
testing the multi-arch and multi-version installers.  Since there are so 
many potential configurations, some thought needs to go into which would 
be of the most value.  I would say that the most important build 
configurations are: (1) 32-bit Intel/PPC framework on 10.5 (and 
eventually 10.6) targeted for 10.3 through 10.6 (the current installer 
config setup); and (2) 32-/64- Intel-only framework for 10.6;  followed 
by (3) 32-/64- Intel/PPC framework for 10.5 and 10.6.  Building the 
whole installer and testing on as many targeted systems as possible 
would be ideal but that adds more complexity to the automation (again, 
not insurmountable).  But even just doing framework multi-arch builds, 
installs, and tests (using the appropriate options) on only the build 
systems themselves without building an installer or third-party libs 
would go a long way towards catching many, if not most, problems early.   
I'd be happy to supply more detailed suggestions for specific 
configuration parameters for those interested in setting up buildbots.   
(There may be some delay, though, as I will have limited time and 
Internet access for the next three 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)

[Ned Deily]

In article <4bc63599.5020...@voidspace.org.uk>,
 Michael Foord  wrote:
> A build on my machine produces output similar to:
> 
> 
> Python build finished, but the necessary bits to build these modules 
> were not found:
> _bsddb

third-party (Sleepycat) library needed (see the installer script)

> dl

only available for 32-bit

> gdbm

third-party library needed (not supplied in the installer build)

> imageop

only available for 32-bit (and removed in 3.x)

> linuxaudiodev  ossaudiodev

neither supported on OS X

> readline

requires either GNU readline lib (not included with OS X) or (with 
2.6.5, trunk, or py3k) can now use OS X editline (libedit) replacement 
when targeting for 10.5 or 10.6 (add MACOSX_DEPLOYMENT_TARGET=10.5 or 
10.6 to ./configure arguments).

> spwd   sunaudiodev

neither supported on OS X

> Failed to build these modules:
> _tkinter

currently only supported for 32-bit archs as there was no 64-bit (non-X) 
Tk on OS X prior to 10.6 and there are unresolved problems with the 10.6 
Apple-supplied Tk 8.5 and 2.6.x IDLE (Issue6864).

-- 
 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)

[Ned Deily]

In article <4bc61278.7020...@v.loewis.de>,
 "Martin v. Lowis"  wrote:
> 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.

Any idea what type of machine it is and where it is currently located?

-- 
 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)

[Michael Foord]

Whilst making Python easier to build on the Mac is certainly a worthy 
goal, the point of my post was to demonstrate (in reply to an email by 
Greg Ewing) *why* building a *full* Python from source was non-trivial. 
I personally only build Python from source to test changes to 
core-Python and am happy with the Python binary installers for the Mac - 
once they arrive. :-)


All the best,

Michael

On 15/04/2010 14:18, Ned Deily wrote:

In article<4bc63599.5020...@voidspace.org.uk>,
  Michael Foord  wrote:
   

A build on my machine produces output similar to:


Python build finished, but the necessary bits to build these modules
were not found:
_bsddb
 

third-party (Sleepycat) library needed (see the installer script)

   

dl
 

only available for 32-bit

   

gdbm
 

third-party library needed (not supplied in the installer build)

   

imageop
 

only available for 32-bit (and removed in 3.x)

   

linuxaudiodev  ossaudiodev
 

neither supported on OS X

   

readline
 

requires either GNU readline lib (not included with OS X) or (with
2.6.5, trunk, or py3k) can now use OS X editline (libedit) replacement
when targeting for 10.5 or 10.6 (add MACOSX_DEPLOYMENT_TARGET=10.5 or
10.6 to ./configure arguments).

   

spwd   sunaudiodev
 

neither supported on OS X

   

Failed to build these modules:
_tkinter
 

currently only supported for 32-bit archs as there was no 64-bit (non-X)
Tk on OS X prior to 10.6 and there are unresolved problems with the 10.6
Apple-supplied Tk 8.5 and 2.6.x IDLE (Issue6864).

   



--
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] Status of 2.7b1?

[Brian Curtin]

On Tue, Apr 13, 2010 at 14:43, David Bolen  wrote:

> Brian Curtin  writes:
>
> > The tests are run on a native Win32 build as compiled by VS2008. The
> > functionality is Win32 specific and wouldn't work on Cygwin, so the tests
> > are skipped there. I believe Cygwin is used for kicking off the tests and
> > other buildbot stuff, but they don't actually run through Cygwin.
>
> Yes, that's correct.  Cygwin is on my buildbot just for management
> convenience.  The build slave happens to be started from a Cygwin bash
> shell (and beneath a Cygwin-based home directory, which is why you see
> it in various path references in logs), but the buildbot code itself
> is responsible for executing the python process directly for testing.
> And python itself is built normally with VS 2008 as a pure win32
> build, no Cygwin dependency.
>
> I did also verify over the weekend that the failures occur whether the
> python_d process is started from a Cygwin bash shell or from the
> normal Windows cmd process, and even if test_os is used directly,
> without running through rt.bat.  The case that ran successfully was
> not via test_os, but only by interactively replicating the test.
>
> I'm back at this point, and to the extent my buildbot is the only
> place currently replicating the problem, am working with Brian for
> whatever access or resources might be helpful.
>
> -- David


Although the fix still needs a bit of cleanup, test_os seems to be working
fine on this buildbot now. The test now waits for the subprocess to
communicate back that it is running, rather than the time.sleep hacks, then
it goes forward with os.kill.

Big thanks to David for access to the machine.
___
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] OS information, tags

[Nick Coghlan]

anatoly techtonik wrote:
> On Tue, Apr 13, 2010 at 3:54 PM, Nick Coghlan  wrote:
>> Or even a separate OS field with "Windows, Mac OS X,
>> Linux, *BSD, Other" as the options?
> 
> It is not uncommon when code written on Unix can affect both MacOS and
> Windows, so you need to be able to select both.

Yep, if adopted, it would be a multi-select field.

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] OS information, tags

[Antoine Pitrou]

Nick Coghlan  gmail.com> writes:
> 
> anatoly techtonik wrote:
> > On Tue, Apr 13, 2010 at 3:54 PM, Nick Coghlan  
> > gmail.com>wrote:
> >> Or even a separate OS field with "Windows, Mac OS X,
> >> Linux, *BSD, Other" as the options?
> > 
> > It is not uncommon when code written on Unix can affect both MacOS and
> > Windows, so you need to be able to select both.
> 
> Yep, if adopted, it would be a multi-select field.

We already have "Macintosh" and "Windows" in the multi-select component field.
It would be nice if the bug interface didn't grow more complicated than it
already is.

Thanks

Antoine.


___
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] OS information, tags

[Nick Coghlan]

Antoine Pitrou wrote:
> Nick Coghlan  gmail.com> writes:
>> anatoly techtonik wrote:
>>> On Tue, Apr 13, 2010 at 3:54 PM, Nick Coghlan  
>>> gmail.com>wrote:
 Or even a separate OS field with "Windows, Mac OS X,
 Linux, *BSD, Other" as the options?
>>> It is not uncommon when code written on Unix can affect both MacOS and
>>> Windows, so you need to be able to select both.
>> Yep, if adopted, it would be a multi-select field.
> 
> We already have "Macintosh" and "Windows" in the multi-select component field.
> It would be nice if the bug interface didn't grow more complicated than it
> already is.

That's where the discussion started - whether or not moving that
information out to a separate field would actually be an improvement or
not. I don't use the tracker intensively enough to give a considered
opinion.

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] OS information, tags

[Antoine Pitrou]

Nick Coghlan  gmail.com> writes:
> 
> That's where the discussion started - whether or not moving that
> information out to a separate field would actually be an improvement or
> not. I don't use the tracker intensively enough to give a considered
> opinion.

For me, the less UI overhead the better.
If people want to search those issues and the Roundup search interface isn't
practical enough (which I understand - most issue trackers seem to have awful
search interfaces), we can predefine custom searches for Windows and Mac issues,
and publish them in the left bar.

Regards

Antoine.


___
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] OS information, tags

[Senthil Kumaran]

On Thu, Apr 15, 2010 at 02:31:23PM +, Antoine Pitrou wrote:
> We already have "Macintosh" and "Windows" in the multi-select component field.
> It would be nice if the bug interface didn't grow more complicated than it
> already is.

+1

There isn't any need for yet another classification.


-- 
Senthil

Your life would be very empty if you had nothing to regret.
___
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] OS information, tags

[Brian Curtin]

On Thu, Apr 15, 2010 at 03:20, anatoly techtonik wrote:

> On Tue, Apr 13, 2010 at 3:54 PM, Nick Coghlan  wrote:
> >
> >>>I am surprised to see that the bug-tracker
> >>> doesn't have an OS classifier or ability to add
> >>> tags ? Since a number of issues reported seem to
>
> Just to remind about my +1 for user editable tags.
>

-sys.maxint on just about anything user editable except for the title or
messages on an issue. I don't think user editable tags on an issue bring
anything to the table except making it seem more "web 2.0". Searching
user-generated tags would be a nightmare because you'd have to know every
combination of some idea in order to get relevant results (e.g., windows,
windoze, window$, win32).
___
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)

[skip]

Ned> Any idea what type of machine it is and where it is currently
Ned> located?

I seem to recall it is/was a G4 XServe.  My guess as to location would be at
xs4all.nl.

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

[Python-Dev] urlparse - to parse IPv6 URL in 2.7 b2 ?

[Senthil Kumaran]

http://bugs.python.org/issue2987 

This deals with a feature request of parsing an IPv6 URL according to
standards. The patch is pretty complete and we have good test coverage
too.

Is it okay to include this in Python 2.7 b2 release?  It would be a
worthy addition.

-- 
Senthil
___
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

[Brett Cannon]

Yes, we have different opinions. My personal take is to wait a week before
you email python-dev if there has been no activity. That is enough time for
people interested in the patch to get to it as we all have different
schedules. Any faster and it feels like noise on the list to me.

Brett (from his phone)

On Apr 14, 2010 11:28 PM, "Glyph Lefkowitz"  wrote:


On Apr 14, 2010, at 5:19 PM, Brett Cannon wrote:

> I see the confusion. I think Martin meant more about open issues that
required discussion, not sim...
Ach.  I hit 'send' too soon.  I also wanted to say: it seemed quite clear to
me that Martin specifically meant "simply issues that had a patch ready to
go".  Quoting him exactly:

Please understand that setting the state of an issue to "review" may
*not* be the best way to trigger a review - it may be more effective
to post to python-dev if you truly believe that the patch can be
committed as-is.

It seems that perhaps the core developers have slightly different opinions
about this? :)
___
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

[Brett Cannon]

Yes, we have different opinions. My personal take is to wait a week before
you email python-dev if there has been no activity. That is enough time for
people interested in the patch to get to it as we all have different
schedules. Any faster and it feels like noise on the list to me.

Brett (from his phone)

On Apr 14, 2010 11:28 PM, "Glyph Lefkowitz"  wrote:

On Apr 14, 2010, at 5:19 PM, Brett Cannon wrote:

> I see the confusion. I think Martin meant more about open issues that
required discussion, not sim...

Ach.  I hit 'send' too soon.  I also wanted to say: it seemed quite clear to
me that Martin specifically meant "simply issues that had a patch ready to
go".  Quoting him exactly:

Please understand that setting the state of an issue to "review" may
*not* be the best way to trigger a review - it may be more effective
to post to python-dev if you truly believe that the patch can be
committed as-is.

It seems that perhaps the core developers have slightly different opinions
about this? :)
___
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]

>>> What's non-trivial about it? 
>> Building a DMG file, in a way that the output will actually work on most
>> other systems.
> 
> As Ronald pointed out, the installer build script does all of the dirty 
> work of building the install disk image (the .dmg file), including 
> downloading and building necessary third-party libraries. 

Hmm. When I tried it last, it didn't do anything - it just crashed. I
then had to fix it, and also arrange to meet a certain number of
assumptions that it assumed but that had not been setup on my system.

This is some years ago, so I don't recall details.

> I think the single most important thing that 
> can be done to help right now is to get a robust system of OS X 
> buildbots going so that many of the critical problems can be detected up 
> front rather than when one of us gets around to building and install 
> testing the multi-arch and multi-version installers.

There is one build slave now up, contributed by David Bolen.

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)

[Martin v. Löwis]

Ned Deily wrote:
> In article <4bc61278.7020...@v.loewis.de>,
>  "Martin v. Lowis"  wrote:
>> 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.
> 
> Any idea what type of machine it is and where it is currently located?

No idea about the former, except that it is an XServe computer. It is
located in Amsterdam (in the Netherlands), in the XS4ALL facility.

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))

[Martin v. Löwis]

> In the first builds, I have noticed that the build master seems to
> execute the builds as a Unix system, so isn't building with the
> universalsdk option or as a framework, though the latter would
> probably need a bit of glue to make the framework available just
> locally to the buildbot process.

Not sure what you mean by "make available" - I thought this is just a
matter of configure options?

Would you like to see such a build on your machine in addition, or
instead of, the Unix build?

> On Windows, the buildbot tasks use scripts that keep the third party
> stuff in the buildbot branch tree itself.  I wonder if perhaps with a
> little TLC, we could come up with some Mac-specific buildbot scripts
> to better have an OSX build slave mimic the final build process.

No. I'd rather create a separate builder on the master.

> I anticipate some tuning to do with respect to external libraries.
> Rather than use system libraries or my own (or finks or MacPorts)
> version of libraries, I suspect it would be better to download the
> same releases of the third party stuff that the installer script
> downloads and install them locally for normal buildbot builds, to best
> match what would be packaged up with a final binary.  Of course, if
> so, then there's the question of keeping the buildbot environment up
> to date with the installer script.

It would be possible to commit these packages into the externals
repository, just as we do for Windows. It would then be possible to
check them out over again all the time, or somehow to detect when the
URL changes so they export a different subversion directory.

> To the extent that the output (DMG) of the build-installer script is
> what is currently needed for OSX, I can generate one if it is still
> needed, though I can't promise much beyond just executing the script.
> The new build slave can also be made available for RMs (or whomever)
> to generate the DMG when needed if that might be helpful.  Though
> there should probably be some basic installation test on other systems
> prior to publishing any such generated files.

For 2.7, I would do that only if the very same build process is also
going to be used for the final release. There is no point in testing
builds when then the final release uses some other process. It would
also be good if anybody who commits to producing OSX binaries now would
also produce them throughout the 2.7 lifetime (which could be a bit
longer than the traditional 18 months).

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] urlparse - to parse IPv6 URL in 2.7 b2 ?

[Martin v. Löwis]

Senthil Kumaran wrote:
> http://bugs.python.org/issue2987 
> 
> This deals with a feature request of parsing an IPv6 URL according to
> standards. The patch is pretty complete and we have good test coverage
> too.
> 
> Is it okay to include this in Python 2.7 b2 release?  It would be a
> worthy addition.

1. The ultimate decision on that is with the release manager (i.e. Benjamin)
2. My personal recommendation is to allow it: while it *is* a new
feature, it is a feature that doesn't change any API.

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] urlparse - to parse IPv6 URL in 2.7 b2 ?

[Antoine Pitrou]

Martin v. Löwis  v.loewis.de> writes:
> > 
[...]
> 2. My personal recommendation is to allow it: while it *is* a new
> feature, it is a feature that doesn't change any API.

That's my opinion too.

Regards

Antoine.


___
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]

In article <19399.11323.946604.992...@montanaro.dyndns.org>,
 s...@pobox.com wrote:

> Ned> Any idea what type of machine it is and where it is currently
> Ned> located?
> 
> I seem to recall it is/was a G4 XServe.  My guess as to location would be at
> xs4all.nl.

If it were working that could be of use.  It would not be able to run OS 
X 10.6 but having a 10.5 system PPC system as a buildbot would certainly 
be useful; it should be fine for the default installer configuration 
builds.  (Alas, I don't expect to be anywhere in the vicinity in the 
foreseeable future.)

-- 
 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)

[Martin v. Löwis]

> If it were working that could be of use.  It would not be able to run OS 
> X 10.6 but having a 10.5 system PPC system as a buildbot would certainly 
> be useful; it should be fine for the default installer configuration 
> builds.  (Alas, I don't expect to be anywhere in the vicinity in the 
> foreseeable future.)

I think we could arrange to have somebody ship it somewhere, even across
the globe.

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)

[Brett Cannon]

On Thu, Apr 15, 2010 at 04:41, Ned Deily  wrote:

> In article <4bc697d2.4020...@v.loewis.de>,
>  "Martin v. Lowis"  wrote:
> > 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.
>
> As Ronald pointed out, the installer build script does all of the dirty
> work of building the install disk image (the .dmg file), including
> downloading and building necessary third-party libraries.   What isn't
> automatically checked at the moment is that the third-party Tk framework
> is in place during the build and that there isn't contamination from the
> build user's environment.  There is a patch in Issue5651 to do much of
> that.  It doesn't currently try to handle the possibility of MacPorts
> (/opt/local) and Fink (/sw) contamination.  I believe that issue should
> be addressed by the resolution of Issue7713.
>

I know for me the reason I have never tried to help with building the
binaries is I simply lack the expertise. I always build straight UNIX
versions of Python under OS X, so I have no experience with framework builds
(which is what the binary distribution is). Heck, I didn't even know about
the build script until just now since it's such a pain to build. Plus I
don't know if you can use a framework build from within your svn checkout
for testing, so I REALLY don't bother building a framework. And to top it
off I use the latest libraries of things to look for possible breakage.

I am sure I am not the only person who has all of these barriers preventing
them from using a framework build consistently.


>
> Keep in mind that Python on OS X supports the standard OS X
> multi-architecture (Intel vs PPC and/or 32-bit vs 64-bit executables in
> the same file) and multi-version features (the current installer builds
> are fully supported on 10.6, 10.5, and 10.4 and "best-effort" supported
> on 10.3 as well although building is not supported on 10.3) as well as
> "Unix" shared library vs OS X framework shared library configurations.
> That leads to a rather imposing matrix of potential build systems vs
> potential target systems.  For the most part, Apple provides excellent
> upward compatibility; downward is somewhat trickier.   OS X 10.6 (Snow
> Leopard) has complicated matters by the change to preferring 64-bit
> building and executing where possible.  For python builds, some build
> configurations that worked by default under 10.5 and earlier no longer
> do so on 10.6, primarily due to standard library modules that depend on
> APIs, in many cases deprecated ones, that are only available in 32-bit
> versions.  The old Macintosh modules comprise the biggest group of these
> and, while they have been removed in 3.x, they still remain in 2.x.  But
> there are some others as well, which explain most of the build issues
> Michael reported.  There are also newer versions of some open source
> libraries in 10.6 which cause problems for multi-version builds:
> openssl, for one, and Apple's 64-bit version of Tk 8.5.
>
> None of these problems are insolvable but with the very limited
> resources (i.e. people time) we've had for working on these issues, and
> when there have been so many other more critical problems, it has been
> easier up to now to stick with building on 10.5 (or even on 10.4 which I
> test build occasionally).  I think the single most important thing that
> can be done to help right now is to get a robust system of OS X
> buildbots going so that many of the critical problems can be detected up
> front rather than when one of us gets around to building and install
> testing the multi-arch and multi-version installers.  Since there are so
> many potential configurations, some thought needs to go into which would
> be of the most value.  I would say that the most important build
> configurations are: (1) 32-bit Intel/PPC framework on 10.5 (and
> eventually 10.6) targeted for 10.3 through 10.6 (the current installer
> config setup); and (2) 32-/64- Intel-only framework for 10.6;  followed
> by (3) 32-/64- Intel/PPC framework for 10.5 and 10.6.  Building the
> whole installer and testing on as many targeted systems as possible
> would be ideal but that adds more complexity to the automation (again,
> not insurmountable).  But even just doing framework multi-arch builds,
> installs, and tests (using the appropriate options) on only the build
> systems themselves without building an installer or third-party libs
> would go a long way towards catching many, if not most, problems early.
> I'd be happy to supply more detailed suggestions for specific
> configuration parameters for those interested in setting up buildbots.
> (There may be some delay, 

Re: [Python-Dev] patch for review: __import__ documentation

[Brett Cannon]

Yes, we have different opinions. My personal take is to wait a week before
you email python-dev if there has been no activity. That is enough time for
people interested in the patch to get to it as we all have different
schedules. Any faster and it feels like noise on the list to me.

Brett (from his phone)

On Apr 14, 2010 11:28 PM, "Glyph Lefkowitz"  wrote:

On Apr 14, 2010, at 5:19 PM, Brett Cannon wrote:

> I see the confusion. I think Martin meant more about open issues that
required discussion, not sim...

Ach.  I hit 'send' too soon.  I also wanted to say: it seemed quite clear to
me that Martin specifically meant "simply issues that had a patch ready to
go".  Quoting him exactly:

Please understand that setting the state of an issue to "review" may
*not* be the best way to trigger a review - it may be more effective
to post to python-dev if you truly believe that the patch can be
committed as-is.

It seems that perhaps the core developers have slightly different opinions
about this? :)
___
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))

[David Bolen]

"Martin v. Löwis"  writes:

> Not sure what you mean by "make available" - I thought this is just a
> matter of configure options?

Building as a framework, yes.  But I think there's some steps to take
to then have the test python binary use the locally built framework
while running the tests (since the framework won't be in a system
location like /Library/Frameworks during the test). Probably similar to
whatever py2app does to use packaged frameworks contained within the
application bundle.

I doubt it's overly complex, but just an extra step that might need to
be incorporated into any buildbot test rules or script to ensure the
just built framework is used in the tests.

> Would you like to see such a build on your machine in addition, or
> instead of, the Unix build?

I suppose an argument could be made to test both, since others have
indicated here they often do a normal Unix-oriented build on OSX, but
I think if I only had to pick one, I'd go with framework to match what
gets published as a binary for downloading.  Theoretically it should
probably also be a universal build, though of course only one variant
would actually get tested on a build slave depending on its platform.

Certainly anything we could do to make the buildbot generated builds
match as closely to possible the distribution binary process would be
beneficial, I'd think.

>> On Windows, the buildbot tasks use scripts that keep the third party
>> stuff in the buildbot branch tree itself.  I wonder if perhaps with a
>> little TLC, we could come up with some Mac-specific buildbot scripts
>> to better have an OSX build slave mimic the final build process.
>
> No. I'd rather create a separate builder on the master.

I'm wondering if I'm saying the same thing but just not using the
right vernacular.  Something on the master (a builder?) for Windows
instructs it to run Tools\buildbot\build.bat for building and test.bat
for testing, rather than each of the individual commands.

Whether we encapsulate the needed logic in separate makefile targets
for the Mac, or independent build scripts like on Windows, the build
master would only need to execute some Mac appropriate command on a
given branch (not sure if that's separate builders), with the
makefile/script in the given checkout handling the third party stuff
and environmental setup.

Keeping the knowledge in the makefile or script in the source tree would
let the rules change across branches without affecting the build master.
Though if having more specific rules in the master was easier, I'd be
fine with that too.

> It would be possible to commit these packages into the externals
> repository, just as we do for Windows. It would then be possible to
> check them out over again all the time, or somehow to detect when the
> URL changes so they export a different subversion directory.

Sure - that's the sort of thing I figured a build script could take
care of, much as it does on Windows.  Or, the current Mac
build-installer script already has the necessary information, and can
be instructed where to place the third party stuff, so it might only
be necessary to have the buildbot process run that script with
appropriate build tree-relative paths.

> For 2.7, I would do that only if the very same build process is also
> going to be used for the final release. There is no point in testing
> builds when then the final release uses some other process.

Agreed, thus my caveat as to the output of the build-installer script
in fact being what has been published for downloads.  In my brief
tests it looks like it created a production DMG ready for publishing
on the download page, and did in fact install correctly, but I'm still
new to the Mac binary building process.

> It would
> also be good if anybody who commits to producing OSX binaries now would
> also produce them throughout the 2.7 lifetime (which could be a bit
> longer than the traditional 18 months).

To the extent that the installer script is in fact the definitive
process, and if the machine (10.4 Intel) is considered suitable as a
binary build platform, then worst case we could probably have the
buildbot run the script and upload the result when needed (sort of a
one-shot version of the old MSI daily builder).  I don't plan on the
machine going away any time soon.

Of course, this is just the DMG construction.  Not sure what amount of
"test the installer" testing should be required prior to publication.

-- David

___
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

[Guido van Rossum]

Comments inline. Nothing showstopping, mostly just spewing obscure
background information...

Overall, congratulations! I'm fine with the implementation going in
and the PEP being marked as accepted as long as you get to the
clarifications I suggest below soon after.

--Guido

On Tue, Apr 13, 2010 at 1:21 PM, 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/
>
> I think the PEP is ready for pronouncement, and the patch is pretty much ready
> for merging into py3k.  The only thing that I can think of that is not
> implemented yet is this section on PEP 302 loaders:
>
>    PEP 302 [18]_ defined loaders have a `.get_filename()` method which
>    points to the `__file__` for a module.  As part of this PEP, we will
>    extend this API, to include a new method `.get_paths()` which will
>    return a 2-tuple containing the path to the source file and the path
>    to where the matching `pyc` file is (or would be).
>
> I'm honestly not sure whether this is still essential, or whether the
> importlib ABC changes Brett and I talked about at Pycon are still required.  I
> now believe they are at best a minor part of the implementation if so.  Maybe
> Brett can chime in on that.

Fine with me to omit.

> Everything else is implemented, tested, and has undergone four rounds of
> Rietveld reviews (thanks Antoine, Benjamin, Brett, and Georg!).  A fifth patch
> set has been uploaded and is available here:
>
> http://codereview.appspot.com/842043/show

TL;DR :-)

> This addresses all previous comments, includes some fixes from Brian Curtin
> for Windows (thanks!) and fixes __main__ and -m support.  I'd like to commit
> this to py3k sooner rather than later so that we can shake out any additional
> issues that might crop up, without having to continue to maintain my external
> branches.
>
> Guido, what say you?
> -Barry
>
> PEP: 3147
> Title: PYC Repository Directories
> Version: $Revision: 80025 $
> Last-Modified: $Date: 2010-04-12 22:17:40 -0400 (Mon, 12 Apr 2010) $
> Author: Barry Warsaw 
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 2009-12-16
> Python-Version: 3.2
> Post-History: 2010-01-30, 2010-02-25, 2010-03-03, 2010-04-12
>
>
> Abstract
> 
>
> This PEP describes an extension to Python's import mechanism which
> improves sharing of Python source code files among multiple installed
> different versions of the Python interpreter.  It does this by
> allowing more than one byte compilation file (.pyc files) to be
> co-located with the Python source file (.py file).  The extension
> described here can also be used to support different Python
> compilation caches, such as JIT output that may be produced by an
> Unladen Swallow [1]_ enabled C Python.
>
>
> Background
> ==
>
> CPython compiles its source code into "byte code", and for performance
> reasons, it caches this byte code on the file system whenever the
> source file has changes.  This makes loading of Python modules much
> faster because the compilation phase can be bypassed.  When your
> source file is `foo.py`, CPython caches the byte code in a `foo.pyc`
> file right next to the source.
>
> Byte code files contain two 32-bit numbers followed by the marshaled

big-endian

> [2]_ code object.  The 32-bit numbers represent a magic number and a
> timestamp.  The magic number changes whenever Python changes the byte
> code format, e.g. by adding new byte codes to its virtual machine.
> This ensures that pyc files built for previous versions of the VM
> won't cause problems.  The timestamp is used to make sure that the pyc
> file is not older than the py file that was used to create it.  When

is not older than -> matches

(Obscure fact: the timestamp in the pyc file must match the source's
mtime exactly.)

> either the magic number or timestamp do not match, the py file is
> recompiled and a new pyc file is written.
>
> In practice, it is well known that pyc files are not compatible across
> Python major releases.  A reading of import.c [3]_ in the Python
> source code proves that within recent memory, every new CPython major
> release has bumped the pyc magic number.
>
>
> Rationale
> =
>
> Linux distributions such as Ubuntu [4]_ and Debian [5]_ provide more
> than one Python version at the same time to their users.  For example,
> Ubuntu 9.10 Karmic Koala users can install Python 2.5, 2.6, and 3.1,
> with Python 2.6 being the default.
>
> This causes a conflict for Python source files installed by the
> system (including third party packages), because you cannot compile a

I'd say only 3rd part packages right? (And code written by the distro,
which from Python's POV is also 3rd party.) At least ought to clarify
that the stdlib is unaffected by this conflict, because multiple
versions of the stdlib *are* installed.

> single Python source file for more than one Python version at a time.
> Thus if 

Re: [Python-Dev] PEP 3147 ready for pronouncement and merging

[Steve Holden]

Guido van Rossum wrote:
[...]
>> Implementation strategy
>> ===
>>
>> This feature is targeted for Python 3.2, solving the problem for those
>> and all future versions.  It may be back-ported to Python 
> 
> Is there time given that 2.7b1 was released?
> 
I would hope we have learned out lesson about cramming new features in
so late in the day, and this *is* a new feature, isn't it? Surely it
therefore can't be added in a bugfix release, which in turn means it
will never be implemented in Python 2 (given that 2.7 is envisaged as
the last Py2 release).

>> Vendors are free to backport the changes to earlier distributions as
>> they see fit.
>>
Really?

>>
>> Effects on existing code
>> 
>>
>> Adoption of this PEP will affect existing code and idioms, both inside
>> Python and outside.  This section enumerates some of these effects.
>>
>>
>> __file__
>> -
>>
>> In Python 3, when you import a module, its `__file__` attribute points
>> to its source `py` file (in Python 2, it points to the `pyc` file).  A
>> package's `__file__` points to the `py` file for its `__init__.py`.
>> E.g.::
>>
>>>>> import foo
>>>>> foo.__file__
>>'foo.py'
>># baz is a package
>>>>> import baz
>>>>> baz.__file__
>>'baz/__init__.py'
>>
>> Nothing in this PEP would change the semantics of `__file__`.
>>
>> This PEP proposes the addition of an `__cached__` attribute to
>> modules, which will always point to the actual `pyc` file that was
>> read or written.  When the environment variable
>> `$PYTHONDONTWRITEBYTECODE` is set, or the `-B` option is given, or if
>> the source lives on a read-only filesystem, then the `__cached__`
>> attribute will point to the location that the `pyc` file *would* have
>> been written to if it didn't exist.  This location of course includes
>> the `__pycache__` subdirectory in its path.
> 
> Hm. I wish there was a way to find out whether the bytecode (or
> whatever) actually *was* read from this file. __file__ in Python 2
> supports this (though not in Python 3).
> 
There also seems to be some complexity in this specification. Does the
intgerpreter go through the analysis of whether the __pycache__
directory could be created in order to provide the correct value for
"the location that the .pyc file would have been written to if it didn't
exist"?

>> For alternative Python implementations which do not support `pyc`
>> files, the `__cached__` attribute may point to whatever information
>> makes sense.  E.g. on Jython, this might be the `.class` file for the
>> module: `__pycache__/foo.jython-32.class`.  Some implementations may
>> use multiple compiled files to create the module, in which case
>> `__cached__` may be a tuple.  The exact contents of `__cached__` are
>> Python implementation specific.
>>
>> It is recommended that when nothing sensible can be calculated,
>> implementations should set the `__cached__` attribute to `None`.
>>
>>
[...]

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] OS information, tags

[Steve Holden]

Brian Curtin wrote:
> On Thu, Apr 15, 2010 at 03:20, anatoly techtonik  > wrote:
> 
> On Tue, Apr 13, 2010 at 3:54 PM, Nick Coghlan  > wrote:
> >
> >>>I am surprised to see that the bug-tracker
> >>> doesn't have an OS classifier or ability to add
> >>> tags ? Since a number of issues reported seem to
> 
> Just to remind about my +1 for user editable tags.
> 
> 
> -sys.maxint on just about anything user editable except for the title or
> messages on an issue. I don't think user editable tags on an issue bring
> anything to the table except making it seem more "web 2.0". Searching
> user-generated tags would be a nightmare because you'd have to know
> every combination of some idea in order to get relevant results (e.g.,
> windows, windoze, window$, win32).
> 

Yes, tight vocabulary control will lead to more consistent classifications.

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)

[Steve Holden]

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 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).
> 
I take it you don't mean to imply that there's a dead person somewhere
with the necessary expertise? [ducks].

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)

[Steve Holden]

Bill Janssen wrote:
> Martin v. Löwis  wrote:
[..]
>> 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.
> 
+1

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] Request for commit access

[Steve Holden]

Martin v. Löwis wrote:
>> That's an ideal case, but it doesn't work, because more or less senior
>> committers are already too busy. If they do not even have time to
>> review issues, followup on patches  - how can they monitor who reached
>> the appropriate karma level?
> 
> The practice proves to be different. In the recent additions, the new
> developer had been approached by some committer, suggesting that they
> apply. So the initiative actually started from a committer who thought
> that the karma level was appropriate. All I'm asking for is that then
> this committer takes the issues in his own hands, rather than letting
> the new developer ask for himself.
> 
That sounds like it should be the preferred procedure, but it may be
that Brian was advised to ask by an existing committer who didn't feel
they had the "authority" to recommend him.

In such an event (or if committers are too busy to action a promising
candidate) I don't see anything wrong with a candidate asking directly
(as long as they are prepared to put up with a semi-public discussion of
their application's merits).

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] Google Groups mirror (Was: Bootstrap script for package management tool in Python 2.7)

[Steve Holden]

anatoly techtonik wrote:
> On Mon, Mar 29, 2010 at 4:50 PM, Tarek Ziadé  wrote:
>> Anatoly, I am now answering only in Distutils-SIG.
>>
>> On Mon, Mar 29, 2010 at 3:45 PM, anatoly techtonik  
>> wrote:
>> [..]
> 
> Seems like I start to hate mailing lists even more with all this
> message duplication and thread following nightmare. Why can't people
> here create a Google Groups mirror?
> 
I would surmise that most people on python-dev do what I do and
subscribe to an NNTP (Usenet news) source. In my case Thunderbird does a
great job of presenting the content, though there is no thread subscription.

Google Groups have their disadvantages too. I personally dislike "web
forum" style interfaces.

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] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))

[Martin v. Löwis]

> Keeping the knowledge in the makefile or script in the source tree would
> let the rules change across branches without affecting the build master.
> Though if having more specific rules in the master was easier, I'd be
> fine with that too.

Intuitively, I find the set of batch files used for Windows "ugly"
(despite me having created them in the first place). Objectively, I
think that has the risk of getting "out of hands", in the sense that
people start to think that they have to use these scripts in order to
build Python on Mac. This actually happened on Windows - some people now
recommend to run the buildbot scripts on a regular developer checkout,
because they supposedly do the right things.

I would rather prefer to have the buildbot run the same commands that we
recommend developers to run. The knowledge about these should be in the
README, and it should be stable knowledge, i.e. require infrequent
changes. This is true for Unix: configure/make/make test/make clean
had been the correct procedure for ten years now. The Unix buildbot only
deviates slightly, to have the slaves run a more expensive version of
the test suite.

> Agreed, thus my caveat as to the output of the build-installer script
> in fact being what has been published for downloads.  In my brief
> tests it looks like it created a production DMG ready for publishing
> on the download page, and did in fact install correctly, but I'm still
> new to the Mac binary building process.

I'd be interested in setting up daily builds then. For these, I think
it's fine that they may differ slightly from the official binaries -
people would recognize that they are testing a different set of binaries.

> Of course, this is just the DMG construction.  Not sure what amount of
> "test the installer" testing should be required prior to publication.

If it's fully automated, the amount of testing may actually be small,
IMO. I personally would put timeliness over correctness here. Also, it
might be that we can sign up some volunteer to do a smoke test in a
timely manner at release time who will test the installer on, say, a
clean VM.

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