Re: Packaging Bokeh
On 2015-09-04 22:44, Diane Trout wrote: > I've made some limited progress trying to package Bokeh (BSD-3-Clause) Many thanks for working this! > I managed to get the version 0.9.1 from pypi installable. (Though since it > was > my own experiments I didn't remove the jquery / bootstrap libraries.) Fortunately, Debian has now a current jQuery 1, again. And jQuery 3 in experimental. Thanks to Antonio Terceiro! Bootstrap is a recent version anyway. So it should be easy to just use Debians packages. > The most proper packaging would require grunt to be able to rebuild bokeh.js. > I was wondering if releasing the pypi version would be good enough. (The > package does at least contain a non-minimized version of bokeh.js) I'm not sure about this, but it looks like the Bokeh source is a huge directory of coffeescript files, while the resulting bokeh.js is not the source code. So build is: 1. coffee -> js 2. concat all js. Maybe its possible without grunt, just like Antonio did with jQuery? > Bokeh's unit tests also appear to depend on blaze, and that looks like that > has several missing dependencies. I would just leave out the tests for now. Bokeh is a huge beast even without them. Let's go step by step. > Thought It looks like the python-modules team is just > about to transition to git-dpm. Yes, that has been decided in Heidelberg, but I'm not sure about the current state. Who can comment on this? > Should I go ahead and submit abstract_rendering? Yes, but please fix the long description. It starts with "Abstract Rendering takes the opposite approach:" which confused me :~) > Should I work on getting > blaze submitted? If blaze is only needed for the tests, I suggest to postpone it. (What is blaze anyway?) Cheers
Bug#798087: ITP: python-poppler-qt5 -- Python binding to Poppler Qt5 C++ library
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: python-poppler-qt5 Version : 0.24.2 Upstream Author : Wilbert Berendsen * URL : https://pypi.python.org/pypi/python-poppler-qt5/ * License : LGPL-2.1+ Programming Lang: Python, SIP Description : Python binding to Poppler Qt5 C++ library Python binding to libpoppler-qt5 that aims for completeness and for being actively maintained. The bindings closely follow the C++ library API documented at http://people.freedesktop.org/~aacid/docs/qt5/ . More information: This is a continuation of Ryan Kavanagh 's great work on python-poppler-qt4 package, but now for Qt5. Its primary "user" in Debian is Frescobaldi the LilyPond sheet music editor, written by the same author, Wilbert Berendsen. I intend to maintain this package inside the Debian Python Modules Team (DPMT) and to have the python-poppler-qt5 source package reside on Alioth.
Bug#797720: ITP: python-ly -- Tool and Python library for manipulating LilyPond files
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: python-ly Version : 0.9.2 Upstream Author : Wilbert Berendsen * URL : https://pypi.python.org/pypi/python-ly * License : GPL-2+ Programming Lang: Python Description : Tool and Python library for manipulating LilyPond files This package provides a Python library `ly` containing various Python modules to parse, manipulate or create documents in LilyPond format. A command line program `ly` is also provided that can be used to do various manipulations with LilyPond files. . The LilyPond format is a plain text input format that is used by the GNU music typesetter LilyPond (www.lilypond.org). 1. Why is this package useful/relevant? Is it a dependency for another package? Answer: python-ly is needed for the Qt4-based LilyPond sheet music editor Frescobaldi 2.18 and above, which I intend to upload after python-ly is accepted. Debian currently has frescobaldi-2.17.2 where the functionality of python-ly was not yet separated out. 2. How do you plan to maintain it? Inside a packaging team? Yes, I intend to join the Debian Python Modules Team (DPMT) to have the python-ly source package reside on Alioth. Frescobaldi, which I co-maintain, is already inside the Python Applications Packaging Team (PAPT).
Re: Packaging Bokeh
> > The most proper packaging would require grunt to be able to rebuild > > bokeh.js. I was wondering if releasing the pypi version would be good > > enough. (The package does at least contain a non-minimized version of > > bokeh.js) > I'm not sure about this, but it looks like the Bokeh source is a > huge directory of coffeescript files, while the resulting > bokeh.js is not the source code. So build is: 1. coffee -> js > 2. concat all js. Maybe its possible without grunt, just like > Antonio did with jQuery? That's a good idea. I'll investigate. > > Yes, but please fix the long description. It starts with > "Abstract Rendering takes the opposite approach:" which confused > me :~) Good point > > > Should I work on getting > > blaze submitted? > > If blaze is only needed for the tests, I suggest to postpone it. > (What is blaze anyway?) As far as I could tell blaze is an implementation of a subset of the numpy/pandas API for talking to like databases and csv files http://blaze.pydata.org/en/latest/ There's several things that spun off and became dependencies of blaze. Probably one of the cooler is Dask. which is multi-core/out of memory numpy arrays & pandas dataframes with some kind of remote execution scheduler. http://dask.pydata.org/en/latest/#
Re: Packaging Bokeh
On Saturday, September 05, 2015 09:28:48 Diane Trout wrote: > > > The most proper packaging would require grunt to be able to rebuild > > > bokeh.js. I was wondering if releasing the pypi version would be good > > > enough. (The package does at least contain a non-minimized version of > > > bokeh.js) > > > > I'm not sure about this, but it looks like the Bokeh source is a > > huge directory of coffeescript files, while the resulting > > bokeh.js is not the source code. So build is: 1. coffee -> js > > 2. concat all js. Maybe its possible without grunt, just like > > Antonio did with jQuery? > > That's a good idea. I'll investigate. It looks like there's something complicated going on with how BokehJS is built. grunt loads some browserfy plugins, one for templates and one for handling coffee script files. It looks like browserfy is providing something like import semantics. Faking grunt with a makefile may be pretty challenging. Diane
