[Sugar-devel] sugar-pippy dependencies

Michel Alexandre Salim michael.silvanus at gmail.com
Tue Sep 29 16:40:12 EDT 2009


On Tue, Sep 29, 2009 at 4:10 PM, Bernie Innocenti <bernie at codewiz.org> wrote:
> El Tue, 29-09-2009 a las 12:36 +0000, Aleksey Lim escribió:

> I suspect the #1 usecase for numpy is to compensate for lack of good
> array support in Python.
>
>
> Questions:
>
> 1) are there lighter-weight alternatives for the most popular uses of
> numpy?
How about numarray?

$ rpm -q --requires python-numarray
/bin/sh
/usr/bin/env
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libm.so.6()(64bit)
libm.so.6(GLIBC_2.2.5)(64bit)
libpthread.so.0()(64bit)
libpython2.6.so.1.0()(64bit)
python(abi) = 2.6
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(VersionedDependencies) <= 3.0.3-1
rtld(GNU_HASH)
rpmlib(PayloadIsXz) <= 5.2-1


> 1) how many of the existing activities actually depend on numpy?
Peter answered this

> 2) would it be hard to remove this dependency from them?
I seem to recall several Python apps moving from numpy to numarray in
the past, so it should be doable. If we want to do this, we should
probably create a tracker bug in Bugzilla.

> 3) Should we define a policy for deprecating components of the Sugar
> Platform in new revisions?  All evolving standards need to find a
> balance between new features with old feature removal to avoid unbounded
> bloat.
That sounds reasonable. Like "new activities using numpy will not be
accepted"? If the porting work from numpy to numarray is documented,
this should be linked to from the policy as well, so that people can
adapt their activities.

> 4) Even if numpy is going to stay around for the Sugar Platform, could
> we remove it from Pippy and other core activities to save resources and
> allow shipping lighter weight live distros?
Probably a good thing to do, yes.

Regards,

--
Michel Alexandre Salim



-- 
Michel Alexandre Salim


More information about the Sugar-devel mailing list