![](https://secure.gravatar.com/avatar/aa1e6549a86e8f2d731110a4c504b851.jpg?s=120&d=mm&r=g)
Something that could raise awareness and expedite the adoption of the Pylab standard under Linux would be the availability of repositories for some of the most common distributions (e.g. Ubuntu, Fedora, RHEL-a-likes). As a number of distributions take a while to catch up with the latest releases of ipython etc making Ubuntu PPA and repos.fedorapeople.org repositories available could provide people with a familar, quick and easy means to install Pylab. Not sure whether we would want distribution package managers automatically upgrading packages though when new Pylab standards/packages are released. Any thoughts? On a related note it might be a good opportunity to bring the fairly-official-looking Scipy PPA [1] up to date. [1] https://launchpad.net/~scipy/+archive/ppa Cheers, Will
![](https://secure.gravatar.com/avatar/a5172a0e32bf445abf49379c67206866.jpg?s=120&d=mm&r=g)
Something that could raise awareness and expedite the adoption of the Pylab standard under Linux would be the availability of repositories for some of the most common distributions (e.g. Ubuntu, Fedora, RHEL-a-likes). As a number of distributions take a while to catch up with the latest releases of ipython etc making Ubuntu PPA and repos.fedorapeople.org repositories available could provide people with a familar, quick and easy means to install Pylab. Not sure whether we would want distribution package managers automatically upgrading packages though when new Pylab standards/packages are released. Any thoughts?
On a related note it might be a good opportunity to bring the fairly-official-looking Scipy PPA [1] up to date.
+1 Just some days ago I registered the pylab team on launchpad, with a 'pylab-stable' PPA: https://launchpad.net/~pylab/+archive/stable However, no packages yet. Anyone wanting to participate send me a note, and I'll take you on the team. Cheers, Andreas.
![](https://secure.gravatar.com/avatar/117fbbd78c11950332ff1df8103e14e0.jpg?s=120&d=mm&r=g)
On 09/25/2012 05:27 AM, Andreas Hilboll wrote:
Something that could raise awareness and expedite the adoption of the Pylab standard under Linux would be the availability of repositories for some of the most common distributions (e.g. Ubuntu, Fedora, RHEL-a-likes). As a number of distributions take a while to catch up with the latest releases of ipython etc making Ubuntu PPA and repos.fedorapeople.org repositories available could provide people with a familar, quick and easy means to install Pylab. Not sure whether we would want distribution package managers automatically upgrading packages though when new Pylab standards/packages are released. Any thoughts?
On a related note it might be a good opportunity to bring the fairly-official-looking Scipy PPA [1] up to date.
Just some days ago I registered the pylab team on launchpad, with a 'pylab-stable' PPA:
https://launchpad.net/~pylab/+archive/stable
However, no packages yet. Anyone wanting to participate send me a note, and I'll take you on the team.
Cheers, Andreas.
Big +1 on this. I am currently stuck supporting ancient versions of numpy because people in my lab (probably rightfully) are not eager to move off their LTS ubuntu's. An officially blessed pylab PPA that they would be willing to trust would be a awesome. Tom
![](https://secure.gravatar.com/avatar/6c8561779fff34c62074c614d19980fc.jpg?s=120&d=mm&r=g)
There is already a Github pylab organization. Can we keep things on Github? -Travis On Sep 25, 2012, at 4:27 AM, Andreas Hilboll wrote:
Something that could raise awareness and expedite the adoption of the Pylab standard under Linux would be the availability of repositories for some of the most common distributions (e.g. Ubuntu, Fedora, RHEL-a-likes). As a number of distributions take a while to catch up with the latest releases of ipython etc making Ubuntu PPA and repos.fedorapeople.org repositories available could provide people with a familar, quick and easy means to install Pylab. Not sure whether we would want distribution package managers automatically upgrading packages though when new Pylab standards/packages are released. Any thoughts?
On a related note it might be a good opportunity to bring the fairly-official-looking Scipy PPA [1] up to date.
+1
Just some days ago I registered the pylab team on launchpad, with a 'pylab-stable' PPA:
https://launchpad.net/~pylab/+archive/stable
However, no packages yet. Anyone wanting to participate send me a note, and I'll take you on the team.
Cheers, Andreas.
_______________________________________________ SciPy-User mailing list SciPy-User@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-user
![](https://secure.gravatar.com/avatar/6c8561779fff34c62074c614d19980fc.jpg?s=120&d=mm&r=g)
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. -Travis On Sep 25, 2012, at 4:27 AM, Andreas Hilboll wrote:
Something that could raise awareness and expedite the adoption of the Pylab standard under Linux would be the availability of repositories for some of the most common distributions (e.g. Ubuntu, Fedora, RHEL-a-likes). As a number of distributions take a while to catch up with the latest releases of ipython etc making Ubuntu PPA and repos.fedorapeople.org repositories available could provide people with a familar, quick and easy means to install Pylab. Not sure whether we would want distribution package managers automatically upgrading packages though when new Pylab standards/packages are released. Any thoughts?
On a related note it might be a good opportunity to bring the fairly-official-looking Scipy PPA [1] up to date.
+1
Just some days ago I registered the pylab team on launchpad, with a 'pylab-stable' PPA:
https://launchpad.net/~pylab/+archive/stable
However, no packages yet. Anyone wanting to participate send me a note, and I'll take you on the team.
Cheers, Andreas.
_______________________________________________ SciPy-User mailing list SciPy-User@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-user
![](https://secure.gravatar.com/avatar/95198572b00e5fbcd97fb5315215bf7a.jpg?s=120&d=mm&r=g)
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. Cheers, f
![](https://secure.gravatar.com/avatar/ad13088a623822caf74e635a68a55eae.jpg?s=120&d=mm&r=g)
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) Josef
Cheers,
f _______________________________________________ SciPy-User mailing list SciPy-User@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-user
![](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.
![](https://secure.gravatar.com/avatar/7f1ae3f14fd5b87c2c3f7b36014e185c.jpg?s=120&d=mm&r=g)
Hi Yaroslav, On 26 September 2012 15:20, Yaroslav Halchenko <lists@onerussian.com> wrote:
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.
The aim certainly isn't to have 'mediocre' packages. I envisage something similar to what you're doing, but for a much smaller set of packages, and a broader audience than neuroscientists. It looks like you're already maintaining ~all of the packages we're interested in, and you've clearly got the repository infrastructure running nicely. From a technical point of view, we could just point users at NeuroDebian, and say "you don't need to be a neuroscientist, just install these general packages". But that doesn't work in terms of perception - people looking for Pylab will think that's a kludge. If I can be bold, perhaps there's a way forward that suits everyone. Would you be prepared to separate out the Pylab packages into another repository that people could use without seeing the entirety of Neurodebian? The source lists for Neurodebian would include the Pylab repository as well, although we'd have to work out what to do for existing subscribers. I imagine there's a bit more effort involved in managing two repositories, but you may have more voluers to help with the Pylab stuff. Then we could point at the Pylab repository as the best way to get Pylab on Debian & Ubuntu - and naturally we'd credit Neurodebian there. Thanks, Thomas
![](https://secure.gravatar.com/avatar/7f1ae3f14fd5b87c2c3f7b36014e185c.jpg?s=120&d=mm&r=g)
Following discussion on the Numfocus list, it looks likely that we *won't* be using the name Pylab after - the Matlab association is felt to be too strong. Scipy is once again the preferred candidate. Thomas
![](https://secure.gravatar.com/avatar/aa1e6549a86e8f2d731110a4c504b851.jpg?s=120&d=mm&r=g)
A point that I don't think has been mentioned so far (correct me if I'm wrong) is whether devising a Scipy standard with recommended/minimum package versions will hinder (or expedite) the transition to Python 3.x. If one package e.g. matplotlib is still Python 2.x only then that would keep the standard 2.7 but may add momentum the development of a 3.x version of that package. More generally, is there any interest in a 3.x Scipy standard, either now or in the next couple of years? Even if there were sufficient 3.x packages to permit both a 2.x and 3.x version of the standard I hope others would agree that this is not a great idea.
![](https://secure.gravatar.com/avatar/7f1ae3f14fd5b87c2c3f7b36014e185c.jpg?s=120&d=mm&r=g)
Hi Will, On 2 October 2012 09:49, Will Furnass <will@thearete.co.uk> wrote:
A point that I don't think has been mentioned so far (correct me if I'm wrong) is whether devising a Scipy standard with recommended/minimum package versions will hinder (or expedite) the transition to Python 3.x. If one package e.g. matplotlib is still Python 2.x only then that would keep the standard 2.7 but may add momentum the development of a 3.x version of that package. More generally, is there any interest in a 3.x Scipy standard, either now or in the next couple of years?
At present, I've put in the standard that 2.x >= 2.6 or 3.x >= 3.2 is valid. Of the current selection of packages, there are three that aren't yet released on Python 3: - matplotlib: coming very soon - SymPy: I think the work is done, but it has yet to be released. Hopefully coming soon (https://github.com/sympy/sympy/pull/1507 ) - Pytables: Still a work in progress, but it *is* being worked on. For now, I think we should steer newcomers towards Python 2, but I don't want the standard to preclude making Python 3 distributions once the necessary packages are there. Pyzo, Almar's distribution, is based on Python 3. Thanks, Thomas
![](https://secure.gravatar.com/avatar/7f1ae3f14fd5b87c2c3f7b36014e185c.jpg?s=120&d=mm&r=g)
So that everyone's aware, there's more discussion of what packages should be in the standard taking place on the NumFOCUS list. If you want to follow it, start reading from about here: https://groups.google.com/d/msg/numfocus/aQKHmlS4m0Y/h8iOeyoruTEJ Thanks, Thomas
![](https://secure.gravatar.com/avatar/a5172a0e32bf445abf49379c67206866.jpg?s=120&d=mm&r=g)
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.
Yes, Neurodebian looks extremely helpful. However, do they package numpy and scipy? I couldn't find it on the package list at http://neuro.debian.net/pkglists/pkgs-by_release-ubuntu_12.04_lts_%22precise... Ubuntu 12.04 is still at scipy 0.9 ... Apart from that, I agree that there isn't be any need to duplicate efforts. Somewhere on the pylab Homepage it should then clearly say something about Neurodebian, and there should be a pylab metapackage on Neurodebian. Cheers, Andreas.
![](https://secure.gravatar.com/avatar/7f1ae3f14fd5b87c2c3f7b36014e185c.jpg?s=120&d=mm&r=g)
On 25 September 2012 23:01, Fernando Perez <fperez.net@gmail.com> wrote:
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.
As I see it, the PPA should be a one-stop-shop for any packages we specify which aren't in the distribution, or where the version in the distribution is too old. If someone else has already packaged it, it should be simple to upload their package, so we won't be duplicating a lot of work. I also intend to make a 'pylab' metapackage which will depend on all the packages in the spec, so users can 'apt-get install pylab'. Returning to earlier discussions: It sounds like we want to specify nose as well. The 1.2 release is quite recent, so let's specify >= 1.1. In the poll about IPython notebook, 30 votes have been cast in favour of including it, and 9 in favour of leaving it out for now. Those who didn't think it should be included: are you willing to concede the point? I'd prefer to avoid rehashing the discussions we've already had, but if there's some key issue that's not yet been mentioned, you can still bring it up. Thanks, Thomas
participants (9)
-
Andreas Hilboll
-
Fernando Perez
-
josef.pktd@gmail.com
-
Thomas Kluyver
-
Tom Dimiduk
-
Travis Oliphant
-
Will Furnass
-
William Furnass
-
Yaroslav Halchenko