[Numpy-discussion] help from OS X 10.5 users wanted
Sat Oct 16 08:32:14 CDT 2010
2010/10/16 Ralf Gommers <firstname.lastname@example.org>:
> On Sat, Oct 16, 2010 at 3:53 AM, Friedrich Romstedt
> <email@example.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.
>> 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
the offending call is logged in
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?
@cmdopts([("python-version=", "p", "python version")])
<calls setupegg.py bdist_mpkg>
<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
(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
>> 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
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)?
More information about the NumPy-Discussion