[Numpy-discussion] help from OS X 10.5 users wanted

Friedrich Romstedt friedrichromstedt@gmail....
Sat Oct 16 08:32:14 CDT 2010


2010/10/16 Ralf Gommers <ralf.gommers@googlemail.com>:
> On Sat, Oct 16, 2010 at 3:53 AM, Friedrich Romstedt
> <friedrichromstedt@gmail.com> wrote:
>> Here come now the interesting facts:
>>
>> 1)  Some tests of numpy failed in 2.0.0.dev.  When the machine is
>> running again I can send the logs.  All some strange-looking typecode
>> string tests with dtype('...') iirc.
>
> Not too surprising, that's the master branch which is not tested much on
> py2.5 / OS X.

Okay.

>> 2)  I noticed that the paver at some late point tried to switch from
>> py2.5 to py2.6, what is rather strange to me.  I must have a look
>> where precisely the build failed for this reason.  py2.6 is the
>> DEFAULT_PYTHON_VERSION (iirc) in pavement.py, and changing it to 2.5
>> fixed it.  Strange.
>
> Did you have the the bootstrap virtualenv set up and active? The following
> should work from a clean checkout:
> paver bootstrap
> source bootstrap/bin/activate
> python setupsconsegg.py install
> paver dmg -p 2.5

At that time my system Python was py2.5.  What I did is in
http://friedrichromstedt.org/numpy/Releases/SystemSetup/2010.rst, and
the offending call is logged in
http://friedrichromstedt.org/numpy/Releases/Logs/10-10-15/paver-dmg.5.log.
 I did not issue the commands you gave before calling $paver dmg.
Also I installed paver using py2.5, and renamed the executable to
paver2.5, to have different pavers for all the Pythons.  Is the -p 2.5
switch fully equivalent?

In pavement.py:

@task
@needs("pdf")
@cmdopts([("python-version=", "p", "python version")])
def dmg(options):
    ...
    _build_mpkg(pyver)

def _build_mpkg(pyver):
    ...
    <calls setupegg.py bdist_mpkg>

in setupegg.py:
<calls just setup.py bdist_mpkg>

So I thought it would create it locally, without using the /Framework
installed numpy libs.  True?

I would like to avoid $pave nuke, since I want to use the same repo
directory for all Python version builds, and $nuke would remove the
other installers.  They shouldn't interfere with each other since the
Python version is encoded in the build directory.  The tasks clean and
clean_bootstrap are okay with me.

Seems that the docs show up with 1.4.1rc1 since I omitted the
$setupsconsegg.py install, the autodoc found the previous install from
the numpy-host/, where I didn't use 2.0.0.dev.

Seems that it surpisingly albeit my irgnorance of the instructions in
pavement.py did work quite nicely.

Can you explain in more detail what the virtualenv is for?  I guess
it's to not install the numpy binaries built into the system's
directory?  Shouldn't there be a $deactivate call before cleaning the
virtualenv?  Why cleaning the virtualenv at all?  I guess I might need
to clean it for the different Pythons to not interfere, but doesn't
virtualenv do the job too?

> If that fails it's a bug. The first build is with python 2.6 if that's your
> default python, it's needed to make sure the docs are built from the exact
> same commit as the binary itself.

"default Python" = DEFAULT_PYTHON in pavement.py?  I guess you mean
the paver Python, the Python used to install Paver.  From the log
http://friedrichromstedt.org/numpy/Releases/Logs/10-10-15/paver-dmg.5.log
(the same as above), the docs were built, and there was no 2.6
installed at that time.  It tried to call py2.6 *after* the successful
call to pdflatex.  I would like to know more about the internals of
the build process, currently it's kind of "gray box" to me.

What is DEFAULT_PYTHON for?  It is used in the options() call in
pavement.py, why?  Else I see no substantial place of use in
pavement.py.

>> 3)  I found no v1.5.1 tag yet (yesterday).  Will the HEAD become 1.5.1?
>
> You mean the master branch? HEAD just points at the most recent commit on
> your currently active branch. In that case no, 1.5.1 will be tagged from the
> maintenance/1.5.x branch. The tag v1.5.1rc1 or v1.5.1 do not exist yet, tags
> are only created once the actual release takes place. So tag v1.5.1rc1
> should appear tomorrow.

Okay, I didn't mention master since:

105osxpython:numpy-deployment Friedrich$ git branch
* master

This was like this from the beginning after $git clone
http://github.com/numpy/numpy.git.  I thought owner-numpy
project-numpy would be the official numpy repo, am I wrong?

Btw: how do I find out what commit a tag is pointing to, and how do I
display those commit's details (using shell git commands)?

Friedrich


More information about the NumPy-Discussion mailing list