![](https://secure.gravatar.com/avatar/634276db962a81d2e8eb008236e8760d.jpg?s=120&d=mm&r=g)
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.