[SciPy-User] [SciPy-user] Pylab - standard packages

Yaroslav Halchenko lists@onerussian....
Wed Sep 26 09:20:07 CDT 2012



josef.pktd wrote:
> 
> On Tue, Sep 25, 2012 at 6:01 PM, Fernando Perez <fperez.net@gmail.com>
> wrote:
>> On Tue, Sep 25, 2012 at 2:55 PM, Travis Oliphant <travis@continuum.io>
>> wrote:
>>> I guess LaunchPad has some nice integrations with PPA concepts.    I
>>> withdraw my recommendation about Github for this purpose.   But, there
>>> is a pylab github account that can be used.
>>
>> Yes a PPA is strictly so that debian/ubuntu/debian-derivative users
>> can add it as a source for automatically-updated packages.
>>
>> Though I'd like to add that our wonderful friends at neurodebian
>> already fill much of this role, I'm not really sure we need a new PPA.
>>  They pretty much package everything we're talking about here, do it
>> on time, and I'd rather encourage reuse and support of their
>> extraordinary efforts than build a new one next to theirs.  If upon
>> closer inspection we find good reasons *not* to use neurodebian, so be
>> it; but let's not *start* by effectively redoing a small piece of what
>> Yarik and Michael have already built up with so much work.
> 
> As far as I understand (not being a Linux user)
> 
> the ppa for pythonxy is mostly a repackaging of the Debian version,
> which for statsmodels and related is mostly Yaroslav's and
> NeuroDebian's work
> https://launchpad.net/~pythonxy
> 
> (advantage for statsmodels: integrated tests of the devel version on
> Ubuntu)
> 

I saw this lovely thread and could not resist to not follow up...  First of
all, thank you Fernando for you kind words!

Indeed it would be a pity if our work gets duplicated... or worse -- claimed
to be done by someone else but the original author (there were precedents)
;) 

But it might be possible avoid duplication at the slight cost of
proliferation of 'supplemental repositories' (e.g. NeuroDebian, and PPAs) if
implemented correctly.  My question (echoing Fernando) would be though --
what contribution such PPA would bring?  One of my main (personal) concerns
about Canonical's PPA is -- its Ubuntu-egocentricity, and lack of Debian
builds.  So, myself, I would not use it, nor depend on it, nor recommend to
our (Debian/NeuroDebian) users.  BUT if those repackaged daily builds
enabled testing (both pandas and statsmodels debian/rules were patched with
DEB_BUILD_OPTIONS=nocheck, thus there is no "integrated tests" Josef ATM) --
I would see a benefit of such PPA existence even for myself and for other
developers to get free CI based on Debian packaging -- it would help me to
eliminate pre- or post-release rebuilds rounds catching out residual
defects.

For the users -- I am not quite sure, besides relatively rare use cases for
people needing to install bleeding edge, unreleased, development version. 
For the released missing ones -- I would invite people just to create
Debian-quality packages (it is not a rocket science) and contribute to
NeuroDebian and_thus/or to Debian (since we upload to the root cause of this
beauty).  Otherwise, with ad-hoc PPA -- these non-official, possible
mediocre, packages, which might not follow the evolution of the official
package in Debian (and thus Ubuntu) -- might diverge from the packaging in
official repositories. Then having differently packaged official and this
PPA-provided development packages might be confusing, might break upgrade
paths, unexpected installation conflicts, etc so users might get "hurt" in
the long run. And that is where proliferation of PPAs would hurt everyone.

Regarding Andreas's comment on fresh numpy/scipy in NeuroDebian:  injecting
such core libraries into the released systems where leaf-packages might not
be compatible with them (and there is no reliable way to check since not
every package has 100% test coverage excercised at build time) would be ...
suboptimal and might break a lot of things, that is why I doubt we would
ever do that for NeuroDebian unless Python world comes up with a good
uniform way to specify version requirements at import time for co-available
multiple versions of the modules.

Summary: PPA, closer following changes in official packages, with daily
builds against upstream code with build-time testing -- gets my vote. 
Additional PPA with simply rebuilds of our packages -- I would not care
less.  PPA providing core package replacing system wide installed ones -- I
will be glad PPAs have no Debian builds.
-- 
View this message in context: http://old.nabble.com/Pylab---standard-packages-tp34450032p34482439.html
Sent from the Scipy-User mailing list archive at Nabble.com.



More information about the SciPy-User mailing list