numpy-discussion

[Numpy-discussion] Numarray-0.5 released

[Todd M. <jm...@st...>]

Release Notes for numarray-0.5

Numarray is an array processing package designed to efficiently
manipulate large multi-dimensional arrays.  Numarray is modelled after
Numeric and features c-code generated from python template scripts,
the capacity to operate directly on arrays in files, and improved type
promotions.

I. ENHANCEMENTS

1. Universal Function Overhead Reduction

The constant time overhead for most universal functions has been reduced
by a factor of 10-20.  This results in better performance for small
arrays.

2. FFT mode and IRAF boundary modes added to Convolve.convolve2d

There's now an FFT switch for the 2d convolution function in the
Convolve package; when set to 1, convolution is performed via the FFT
rather than using the naiive algorithm.  In addition, convolve2d now
supports boundary modes which are identical to IRAF's convolution
function.

3. Numarray is now supported by f2py

Numarray numerical arrays can now be used with f2py wrappers for
Fortran code.  To compile f2py wrapped extensions for numarray,
use the switch -DNUMARRAY on the f2py command line. Support
is currently limited to f77 and numerical arrays.


II. BUGS FIXED

650926        exotic type coercions
653424        Convolve.boxcar boundary bug
653429        python setup.py build
654669        array index by list
655942        logical operator reductions
657058        inverse real fft bug
677796         byteswap not working
709956        error summing over large boolean arrays
710480        MLab.median makes unnecessary msort call
714537        conjugate function changes its argument

See
http://sourceforge.net/tracker/?atid=450446&group_id=1369&func=browse
for more details.

III. CAUTIONS

1. Due to some module renamings, numarray-0.5 will not install
correctly on top of an existing numarray installation. Before
installing numarray-0.5 remove your old version of numarray.

2. Due to reorganization of the C-API, numarray extensions must be
recompiled.

3. For numarray-0.5 and up, the byteswap related methods have been
redefined:

a.byteswap()                   swaps but leaves byteorder alone
a.togglebyteorder()            Does "big" <-> "little"
a._byteswap()                  now an alias for byteswap
a._togglebyteorder()           deleted

4. round() has been deprecated.  Use around() instead.

5. Installing from source, the first time you run setup.py, you must
specify --gencode, e.g.:  python setup.py install --gencode

WHERE
-----------

Numarray-0.5 windows executable installers, source code, and manual is
here:

http://sourceforge.net/project/showfiles.php?group_id=1369

Numarray is hosted by Source Forge in the same project which hosts
Numeric:

http://sourceforge.net/projects/numpy/

The web page for Numarray information is at:

http://stsdas.stsci.edu/numarray/index.html

Trackers for Numarray Bugs, Feature Requests, Support, and Patches are
at
the Source Forge project for NumPy at:

http://sourceforge.net/tracker/?group_id=1369

REQUIREMENTS
------------------------------

numarray-0.5 requires Python 2.2.2 or greater.


AUTHORS, LICENSE
------------------------------

Numarray was written by Perry Greenfield, Rick White, Todd Miller, JC
Hsu, Paul Barrett, Phil Hodge at the Space Telescope Science
Institute.  Thanks go to Jochen Kupper of the University of North
Carolina for his work on Numarray and for porting the Numarray manual
to TeX format.  Thanks also to Edward C. Jones, Francesc Alted,
Paul Dubois, Eric Jones, Travis Oliphant, Pearu Peterson and everyone
who has contributed with comments and feedback.

Numarray is made available under a BSD-style License.  See
LICENSE.txt in the source distribution for details.

-- 
Todd Miller 			jm...@st...
STSCI / ESS / SSB

[Numpy-discussion] http://stsdas.stsci.edu/numarray outdated

[Sebastian H. <ha...@ms...>]

Hi all,
I'm happy to hear about the new release !
Could someone put this information on the web ?
http://stsdas.stsci.edu/numarray/
still dates to 2002 Aug (which is before 0.4 !!)

Or is this page the wrong page anyway -- I just end up there because google
points into that direction when you ask for 'numarray'

Thanks for the great work.
Sebastian




----- Original Message ----- 
From: "Todd Miller" <jm...@st...>
To: <num...@li...>
Sent: Monday, May 05, 2003 5:11 AM
Subject: [Numpy-discussion] Numarray-0.5 released


> Release Notes for numarray-0.5
>
> Numarray is an array processing package designed to efficiently
> manipulate large multi-dimensional arrays.  Numarray is modelled after
> Numeric and features c-code generated from python template scripts,
> the capacity to operate directly on arrays in files, and improved type
> promotions.
>
> I. ENHANCEMENTS
>
> 1. Universal Function Overhead Reduction
>
> The constant time overhead for most universal functions has been reduced
> by a factor of 10-20.  This results in better performance for small
> arrays.
>
> 2. FFT mode and IRAF boundary modes added to Convolve.convolve2d
>
> There's now an FFT switch for the 2d convolution function in the
> Convolve package; when set to 1, convolution is performed via the FFT
> rather than using the naiive algorithm.  In addition, convolve2d now
> supports boundary modes which are identical to IRAF's convolution
> function.
>
> 3. Numarray is now supported by f2py
>
> Numarray numerical arrays can now be used with f2py wrappers for
> Fortran code.  To compile f2py wrapped extensions for numarray,
> use the switch -DNUMARRAY on the f2py command line. Support
> is currently limited to f77 and numerical arrays.
>
>
> II. BUGS FIXED
>
> 650926        exotic type coercions
> 653424        Convolve.boxcar boundary bug
> 653429        python setup.py build
> 654669        array index by list
> 655942        logical operator reductions
> 657058        inverse real fft bug
> 677796         byteswap not working
> 709956        error summing over large boolean arrays
> 710480        MLab.median makes unnecessary msort call
> 714537        conjugate function changes its argument
>
> See
> http://sourceforge.net/tracker/?atid=450446&group_id=1369&func=browse
> for more details.
>
> III. CAUTIONS
>
> 1. Due to some module renamings, numarray-0.5 will not install
> correctly on top of an existing numarray installation. Before
> installing numarray-0.5 remove your old version of numarray.
>
> 2. Due to reorganization of the C-API, numarray extensions must be
> recompiled.
>
> 3. For numarray-0.5 and up, the byteswap related methods have been
> redefined:
>
> a.byteswap()                   swaps but leaves byteorder alone
> a.togglebyteorder()            Does "big" <-> "little"
> a._byteswap()                  now an alias for byteswap
> a._togglebyteorder()           deleted
>
> 4. round() has been deprecated.  Use around() instead.
>
> 5. Installing from source, the first time you run setup.py, you must
> specify --gencode, e.g.:  python setup.py install --gencode
>
> WHERE
> -----------
>
> Numarray-0.5 windows executable installers, source code, and manual is
> here:
>
> http://sourceforge.net/project/showfiles.php?group_id=1369
>
> Numarray is hosted by Source Forge in the same project which hosts
> Numeric:
>
> http://sourceforge.net/projects/numpy/
>
> The web page for Numarray information is at:
>
> http://stsdas.stsci.edu/numarray/index.html
>
> Trackers for Numarray Bugs, Feature Requests, Support, and Patches are
> at
> the Source Forge project for NumPy at:
>
> http://sourceforge.net/tracker/?group_id=1369
>
> REQUIREMENTS
> ------------------------------
>
> numarray-0.5 requires Python 2.2.2 or greater.
>
>
> AUTHORS, LICENSE
> ------------------------------
>
> Numarray was written by Perry Greenfield, Rick White, Todd Miller, JC
> Hsu, Paul Barrett, Phil Hodge at the Space Telescope Science
> Institute.  Thanks go to Jochen Kupper of the University of North
> Carolina for his work on Numarray and for porting the Numarray manual
> to TeX format.  Thanks also to Edward C. Jones, Francesc Alted,
> Paul Dubois, Eric Jones, Travis Oliphant, Pearu Peterson and everyone
> who has contributed with comments and feedback.
>
> Numarray is made available under a BSD-style License.  See
> LICENSE.txt in the source distribution for details.
>
> -- 
> Todd Miller jm...@st...
> STSCI / ESS / SSB
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

[Numpy-discussion] [numarray issue] nonzero? Comments on new name solicited

[Perry G. <pe...@st...>]

[In the next week or so I am going to be raising some issues
regarding the next numarray release, 0.6. By the way, we keep the
version number less than 1.0 because we still hold out the
possiblity of changing some interface issues (generally it has
been in the direction of making numarray more compatible with
Numeric). The following raises one of these interface issues.

numarray has a more general approach to the nonzero function 
than does Numeric. It is able to return multiple index arrays
for multidimensional arrays (where as nonzero only works for
1-d arrays). In the interest of giving a more generic interface
for the function, numarray always returns the index array(s)
as part of a tuple, even if the argument to nonzero is 1-D and
there is only one resulting index array.

However, this is a problem for Numeric old code that uses nonzero
and expects an array instead of a tuple. The sensible thing to do
is to retain  compatibilty with the Numeric nonzero (and likewise
only  support 1-d arrays). So we need a new name for our new nonzero
function. To tell you the truth, I always felt that nonzero
was a terrible name anyway and much preferred the name that
IDL used for that function, namely "where". Alas, "where" is
already used for another purpose in Numeric. But to illustrate,
which is clearer?

x[nonzero(x > 0.)] = 0.

or

x[where(x > 0.)] = 0

So, we considered some other alternatives, in particular

nz
wheretrue 

but our favorite is: "at". For example:

x[at(x > 0.)] = 0.

This has the benefit of being short and having a fairly clear
meaning. Short is important since it will keep expressions
of arrays using index arrays short and more readable.

True, this is more likely to conflict with existing user variable or
function names,  but if one is simply trying to use existing files,
then there is no problem since they won't need the "at" function since
its functionality was not previously available.

Any objections to using "at"? Any better suggestions.

Of course, these changes will break existing numarray code that
use the nonzero function.

Perry Greenfield

[Numpy-discussion] Re: [SciPy-user] [numarray issue] nonzero? Comments on new name solicited

[Pearu P. <pe...@ce...>]

On Mon, 5 May 2003, Perry Greenfield wrote:

> Any objections to using "at"? Any better suggestions.

For me 'wheretrue' sounds most accurate but I agree, it's longish.

Its short form 'where' is less accurate (because of its general
meaning) but not too confusing.

At first, 'at' confused me a little... until I figured out its long
version 'trueat'.

Hmm, I have always assumed that 'nonzero(x)' means elementwise 
'not not x' (like Python __nonzero__ is equivalent to 'not not') and
therefore never felt the need to use it.
But now I see I was wrong! So, 'nonzero' sounded and still 
sounds misleading for me.

For 'nz' I am -1 because 'nz' can often be a suitable variable name.

In summary, I would like 'trueat' the most and 'nonzero' the least.
'where' and 'at' (in that order) are somewhere in between.

Pearu

[Numpy-discussion] Re: [SciPy-user] [numarray issue] nonzero? Comments on new name solicited

[Stan H. <st...@st...>]

"Perry Greenfield" <pe...@st...> writes:

> Any objections to using "at"? 

no, "at" reads reasonably well.

> Any better suggestions.

"suchthat"?

-- 
Stan

[Numpy-discussion] Re: [SciPy-user] [numarray issue] nonzero? Comments on new name solicited

[Agustin L. <al...@ij...>]

suchdat would make the programs much easier
to read, very good idea.

Agus

Dr. Agustin Lobo
Instituto de Ciencias de la Tierra (CSIC)
Lluis Sole Sabaris s/n
08028 Barcelona SPAIN
tel 34 93409 5410
fax 34 93411 0012
al...@ij...


On 6 May 2003, Stan Heckman wrote:

> "Perry Greenfield" <pe...@st...> writes:
> 
> > Any objections to using "at"? 
> 
> no, "at" reads reasonably well.
> 
> > Any better suggestions.
> 
> "suchthat"?
> 
> -- 
> Stan
> _______________________________________________
> SciPy-user mailing list
> Sci...@sc...
> http://www.scipy.net/mailman/listinfo/scipy-user
> 

[Numpy-discussion] Re: [SciPy-user] [numarray issue] nonzero? Comments on new name solicited

[Agustin L. <al...@ij...>]

I meant "suchthat" (not "suchdat"), of course. The "spanglish" spelling
would be confusing for others!
Agus


On Wed, 7 May 2003, Agustin Lobo wrote:

> suchdat would make the programs much easier
> to read, very good idea.
> 
> Agus
> 
> Dr. Agustin Lobo
> Instituto de Ciencias de la Tierra (CSIC)
> Lluis Sole Sabaris s/n
> 08028 Barcelona SPAIN
> tel 34 93409 5410
> fax 34 93411 0012
> al...@ij...
> 
> 
> On 6 May 2003, Stan Heckman wrote:
> 
> > "Perry Greenfield" <pe...@st...> writes:
> > 
> > > Any objections to using "at"? 
> > 
> > no, "at" reads reasonably well.
> > 
> > > Any better suggestions.
> > 
> > "suchthat"?
> > 
> > -- 
> > Stan
> > _______________________________________________
> > SciPy-user mailing list
> > Sci...@sc...
> > http://www.scipy.net/mailman/listinfo/scipy-user
> > 
> _______________________________________________
> SciPy-user mailing list
> Sci...@sc...
> http://www.scipy.net/mailman/listinfo/scipy-user
> 

[Numpy-discussion] [numarray] packaging and names

[Perry G. <pe...@st...>]

There was general consensus that numarray should be organized as a
package. We are about to start doing so. It does raise some
issues (and opportunities) however.

1) What should the package be called? numarray is a possiblity, 
but we have an opportunity to take a different approach. For 
example if we could name the package "array" (unfortunately,
we can't) then the following becomes possible (these are just
examples, we haven't settled on any naming scheme yet).

from array.numeric import * # instead of "from numarray import *"
import array.fft
import array.records # currently recarray

Since array is not avaible (there is already an array module
in the Python Standard Library) what are the alternatives?

Here are some:

num
numarray
arr
arrays
ndarray

I've polled people locally and arrays and ndarray were the most
popular, but there doesn't seem to be a clear winner. I tend toward
arr somewhat because of the brevity but do realize it isn't
terribly descriptive. The drawback of "arrays" is that it may be
visually confused with array.

2) What to call the package components?

Locally the favorites were

numarray --> numeric
recarray --> records
chararray--> strings (but since we plan to implement PyObject arrays
                      there is a possibilty of real Python string arrays)
ndarray  --> generic (or base)

3) Where to place 3rd party array extension modules (by that I 
mean all those not distributed with numarray)? Should 
they go in the package directory? I'd prefer that they go
into a separate directory from the things that are part
of the standard numarray distribution (a site-packages
equivalent in the package?)

4) We would likely also include in the package
numarray.py, recarray.py, chararray.py, ndarray.py
so that if the package was added to the path, the current imports
would continue to work. This is intended as a short-term measure
(i.e., they are deprecated and will disappear at version 1.0, or
earlier). We may also keep these files at the current nummarray
interface so that some of the software we currently distribute
does not need to change immediately to match the changes we have been
talking about.

We realize that these are big changes, but if we move to a package
structure, we ought to think about what makes the most sense (and if
it is any comfort, we suffer the consequences of change more than
anyone else). Better now than later.

Screams?

Perry

[Numpy-discussion] RE: [SciPy-user] [numarray issue] nonzero? Comments on new name solicited

[Perry G. <pe...@st...>]

Some one suggested that numarray ditch compatibility in this 
area and "do what's right". Namely he suggested that

nonzero --> where
where   --> select

I have to agree that these are far better names than the
existing ones. But compatibilty is important. So what to do?

Here's one suggestion; I'm curious what people think about
this solution. Nothing prevents us from having a module that
people would import for Numeric compatibilty and a different one
that has somewhat different behavior. Before people start throwing
rocks (when you finish reading you can throw them ;-) and say "didn't
you say that customized versions of Numeric or numarray were a 
bad idea?" Yes I did. But I think some customizations are bad
and perhaps some are acceptable.

What I objected to was having array objects with different behavior
Since array objects may be passed between modules that assume
different behaviors, that will cause all sorts of problems
(e.g., module A was written assuming array slices are views
but is passed an array that produces a copy when sliced).

But is there any harm when all that is different are module functions?
These are unlikely to be passed from one module to another and thus
the customization is localized to the user modules. Suppose that
the Numeric-compatible version defines "where" and "nonzero" to have
their current meanings and numarray uses "select", and "where" 
respectively.

There is one case that could arise that might cause problems. About
the only time a problem would occur is if someone did 

from numarray import *
from B import *

And in B.py

from Numericcompatible import *

in which case the numarray "where" is replaced by the Numeric "where"

I don't know if this is a strong enough reason to support two different
flavors, but what do people think of taking this approach? Are there
any other module functions that would benefit from such changes in name
or behavior (For example, the axis order issue)?

Perry Greenfield

[Numpy-discussion] numarray 0.5 -> python setup.py build fails

[Sebastian H. <ha...@ms...>]

Hi,
I just tried this :
haase@baboon:~/numarray-0.5: python2.2 setup.py build --gencode
<snip>

creating /usr/lib/python2.2/site-packages/numarray
error: could not create '/usr/lib/python2.2/site-packages/numarray':
Permission denied

I guess this is the same bug I ran into a couple month ago - I already now a
workaround ...

- Sebastian



----- Original Message ----- 
From: "Todd Miller" <jm...@st...>
To: <num...@li...>
Sent: Monday, May 05, 2003 5:11 AM
Subject: [Numpy-discussion] Numarray-0.5 released


> Release Notes for numarray-0.5
>
> Numarray is an array processing package designed to efficiently
> manipulate large multi-dimensional arrays.  Numarray is modelled after
> Numeric and features c-code generated from python template scripts,
> the capacity to operate directly on arrays in files, and improved type
> promotions.
>
> I. ENHANCEMENTS
>
> 1. Universal Function Overhead Reduction
>
> The constant time overhead for most universal functions has been reduced
> by a factor of 10-20.  This results in better performance for small
> arrays.
>
> 2. FFT mode and IRAF boundary modes added to Convolve.convolve2d
>
> There's now an FFT switch for the 2d convolution function in the
> Convolve package; when set to 1, convolution is performed via the FFT
> rather than using the naiive algorithm.  In addition, convolve2d now
> supports boundary modes which are identical to IRAF's convolution
> function.
>
> 3. Numarray is now supported by f2py
>
> Numarray numerical arrays can now be used with f2py wrappers for
> Fortran code.  To compile f2py wrapped extensions for numarray,
> use the switch -DNUMARRAY on the f2py command line. Support
> is currently limited to f77 and numerical arrays.
>
>
> II. BUGS FIXED
>
> 650926        exotic type coercions
> 653424        Convolve.boxcar boundary bug
> 653429        python setup.py build
> 654669        array index by list
> 655942        logical operator reductions
> 657058        inverse real fft bug
> 677796         byteswap not working
> 709956        error summing over large boolean arrays
> 710480        MLab.median makes unnecessary msort call
> 714537        conjugate function changes its argument
>
> See
> http://sourceforge.net/tracker/?atid=450446&group_id=1369&func=browse
> for more details.
>
> III. CAUTIONS
>
> 1. Due to some module renamings, numarray-0.5 will not install
> correctly on top of an existing numarray installation. Before
> installing numarray-0.5 remove your old version of numarray.
>
> 2. Due to reorganization of the C-API, numarray extensions must be
> recompiled.
>
> 3. For numarray-0.5 and up, the byteswap related methods have been
> redefined:
>
> a.byteswap()                   swaps but leaves byteorder alone
> a.togglebyteorder()            Does "big" <-> "little"
> a._byteswap()                  now an alias for byteswap
> a._togglebyteorder()           deleted
>
> 4. round() has been deprecated.  Use around() instead.
>
> 5. Installing from source, the first time you run setup.py, you must
> specify --gencode, e.g.:  python setup.py install --gencode
>
> WHERE
> -----------
>
> Numarray-0.5 windows executable installers, source code, and manual is
> here:
>
> http://sourceforge.net/project/showfiles.php?group_id=1369
>
> Numarray is hosted by Source Forge in the same project which hosts
> Numeric:
>
> http://sourceforge.net/projects/numpy/
>
> The web page for Numarray information is at:
>
> http://stsdas.stsci.edu/numarray/index.html
>
> Trackers for Numarray Bugs, Feature Requests, Support, and Patches are
> at
> the Source Forge project for NumPy at:
>
> http://sourceforge.net/tracker/?group_id=1369
>
> REQUIREMENTS
> ------------------------------
>
> numarray-0.5 requires Python 2.2.2 or greater.
>
>
> AUTHORS, LICENSE
> ------------------------------
>
> Numarray was written by Perry Greenfield, Rick White, Todd Miller, JC
> Hsu, Paul Barrett, Phil Hodge at the Space Telescope Science
> Institute.  Thanks go to Jochen Kupper of the University of North
> Carolina for his work on Numarray and for porting the Numarray manual
> to TeX format.  Thanks also to Edward C. Jones, Francesc Alted,
> Paul Dubois, Eric Jones, Travis Oliphant, Pearu Peterson and everyone
> who has contributed with comments and feedback.
>
> Numarray is made available under a BSD-style License.  See
> LICENSE.txt in the source distribution for details.
>
> -- 
> Todd Miller jm...@st...
> STSCI / ESS / SSB
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] numarray 0.5 -> python setup.py build fails

[Francesc A. <fa...@op...>]

I guess this is a problem with permissions. It seems like if setup.py is
trying to install numarray on the Python site-packages directory. It shou=
ld
not, but meanwhile, run this command as root and it should works. Ah!, do
not forget to delete (or better, move) the old site-packages/numarray in
order to do a problem-free fresh installation. Remember:

> > 1. Due to some module renamings, numarray-0.5 will not install
> > correctly on top of an existing numarray installation. Before
> > installing numarray-0.5 remove your old version of numarray.

Cheers,

A Dimarts 06 Maig 2003 03:24, Sebastian Haase va escriure:
> Hi,
> I just tried this :
> haase@baboon:~/numarray-0.5: python2.2 setup.py build --gencode
> <snip>
>
> creating /usr/lib/python2.2/site-packages/numarray
> error: could not create '/usr/lib/python2.2/site-packages/numarray':
> Permission denied
>
> I guess this is the same bug I ran into a couple month ago - I already =
now
> a workaround ...
>
> - Sebastian
>

--=20
Francesc Alted

Re: [Numpy-discussion] numarray 0.5 -> python setup.py build fails

[Sebastian H. <ha...@ms...>]

The reason that I always try "setup.py BUILD" first is that I don't have
root permissions on that machine - so this is a quite important "test" for
me.
Thanks,
Sebastian

----- Original Message ----- 
From: "Francesc Alted" <fa...@op...>
To: "Sebastian Haase" <ha...@ms...>;
<num...@li...>
Sent: Tuesday, May 06, 2003 7:19 AM
Subject: Re: [Numpy-discussion] numarray 0.5 -> python setup.py build fails


I guess this is a problem with permissions. It seems like if setup.py is
trying to install numarray on the Python site-packages directory. It should
not, but meanwhile, run this command as root and it should works. Ah!, do
not forget to delete (or better, move) the old site-packages/numarray in
order to do a problem-free fresh installation. Remember:

> > 1. Due to some module renamings, numarray-0.5 will not install
> > correctly on top of an existing numarray installation. Before
> > installing numarray-0.5 remove your old version of numarray.

Cheers,

A Dimarts 06 Maig 2003 03:24, Sebastian Haase va escriure:
> Hi,
> I just tried this :
> haase@baboon:~/numarray-0.5: python2.2 setup.py build --gencode
> <snip>
>
> creating /usr/lib/python2.2/site-packages/numarray
> error: could not create '/usr/lib/python2.2/site-packages/numarray':
> Permission denied
>
> I guess this is the same bug I ran into a couple month ago - I already now
> a workaround ...
>
> - Sebastian
>

-- 
Francesc Alted


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

_______________________________________________
Numpy-discussion mailing list
Num...@li...
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] numarray 0.5 -> python setup.py build fails

[Todd M. <jm...@st...>]

Sebastian Haase wrote:

>Hi,
>I just tried this :
>haase@baboon:~/numarray-0.5: python2.2 setup.py build --gencode
><snip>
>
>creating /usr/lib/python2.2/site-packages/numarray
>error: could not create '/usr/lib/python2.2/site-packages/numarray':
>Permission denied
>
>I guess this is the same bug I ran into a couple month ago - I already now a
>workaround ...
>
>- Sebastian
>  
>
Here's a couple work arounds I use:

1) When trying to install to /usr/lib,  I first "su root".

2) When I don't like to or can't "su root",  I first install Python in 
my home directory using: "./configure --prefix=$HOME".  With a local 
Python, site-packages is also local and writeable by default.

That said, setup.py has some kludges in it that need to be eliminated or 
factored out.

Todd

Re: [Numpy-discussion] numarray 0.5 -> python setup.py build fails

[Todd M. <jm...@st...>]

Todd Miller wrote:

> Sebastian Haase wrote:
>
>> Hi,
>> I just tried this :
>> haase@baboon:~/numarray-0.5: python2.2 setup.py build --gencode
>> <snip>
>>
>> creating /usr/lib/python2.2/site-packages/numarray
>> error: could not create '/usr/lib/python2.2/site-packages/numarray':
>> Permission denied
>>
>> I guess this is the same bug I ran into a couple month ago - I 
>> already now a
>> workaround ...
>>
>> - Sebastian
>>  
>>
> Here's a couple work arounds I use:
>
> 1) When trying to install to /usr/lib,  I first "su root".
>
> 2) When I don't like to or can't "su root",  I first install Python in 
> my home directory using: "./configure --prefix=$HOME".  With a local 
> Python, site-packages is also local and writeable by default.
>
> That said, setup.py has some kludges in it that need to be eliminated 
> or factored out.
>
> Todd
>
A third method,  a little less onerous than the first two, is:

3) mkdir $HOME/numarray;  python setup.py build --gencode 
--local=$HOME/numarray

This works OK even if you're using a Python which does not have a 
writeable site-packages directory.

>
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] numarray 0.5 -> python setup.py build fails

[Fernando P. <fp...@co...>]

Todd Miller wrote:

>>Here's a couple work arounds I use:
>>
>>1) When trying to install to /usr/lib,  I first "su root".
>>
>>2) When I don't like to or can't "su root",  I first install Python in 
>>my home directory using: "./configure --prefix=$HOME".  With a local 
>>Python, site-packages is also local and writeable by default.
>>
>>That said, setup.py has some kludges in it that need to be eliminated 
>>or factored out.
>>
>>Todd
>>
> 
> A third method,  a little less onerous than the first two, is:
> 
> 3) mkdir $HOME/numarray;  python setup.py build --gencode 
> --local=$HOME/numarray
> 
> This works OK even if you're using a Python which does not have a 
> writeable site-packages directory.

My apologies if I'm off-base, but I'm pretty sure that a properly written 
setup.py should not try to write anywhere but in the build/ subdirectory when 
invoked with the 'build' option.  It should only write in site-packages when 
called with 'install'.

I rely on this fact all the time, by first building packages and then calling 
'setup.py install' separately.  And I do this as a non-root user always.

I could be wrong, but if setup.py is trying to write at build (not install) 
time into /usr/lib/..., I think that should be considered a bug.

Best,

f.

Re: [Numpy-discussion] numarray 0.5 -> python setup.py build fails

[Fernando P. <fp...@co...>]

Fernando Perez wrote:

> I rely on this fact all the time, by first building packages and then calling 
> 'setup.py install' separately.  And I do this as a non-root user always.

Clarification: I call 'build' as non-root, then 'install' as root.  Same as doing:

make
su
make install

in python it's

setup.py build
su
setup.py install

Cheers,

f.