Bug#969620: ITP: metakernel -- Jupyter kernel base class
Package: wnpp Severity: wishlist Owner: Joseph Nahmias * Package name: metakernel Version : 0.27.0 Upstream Author : Metakernel Development Team * URL : https://github.com/Calysto/metakernel * License : BSD Programming Lang: Python Description : Jupyter kernel base class Metakernel is a Jupyter kernel base class in Python which includes core magic functions (including help, command and file path completion, parallel and distributed processing, downloads, and much more). It is used by numerous other kernels for Jupyter, including for my purposes the octave kernel. Happy to have co-maintainers and/or place it under the rubric of the Debian Python team. --Joe
Bug#969708: ITP: ipyparallel -- Interactive Parallel Computing with IPython
Package: wnpp Severity: wishlist Owner: Joseph Nahmias * Package name: ipyparallel Version : 6.3.0 Upstream Author : The IPython Development Team * URL : https://github.com/ipython/ipyparallel * License : BSD Programming Lang: Python Description : Interactive Parallel Computing with IPython ipyparallel is a Python package and collection of CLI scripts for controlling clusters for Jupyter. ipyparallel is the new home of IPython.parallel. . ipyparallel contains the following CLI scripts: . ipcluster - start/stop a cluster ipcontroller - start a scheduler ipengine - start an engine ipyparallel is a dependancy for the Jupyter metakernel. As with metakernel, looking to maintain this within the DPMT.
Bug#976622: ITP: python3-oscrypto -- cryptography library for Python
Package: wnpp Severity: wishlist * Package name: python3-oscrypto Version : 1.2.1 Upstream Author : Will Bond * URL : https://github.com/wbond/oscrypto * License : MIT Programming Lang: Python Description : cryptography library for Python TLS (SSL) sockets, key generation, encryption, decryption, signing, verification and KDFs using the OS crypto libraries. Does not require a compiler, and relies on the OS for patching. Works on Windows, OS X and Linux/BSD. I plan to maintain this under the Debian Python Team. Used by a number of cross-platform projects including for verifying LineageOS builds.
Bug#975509: ITP: nbdime -- Jupyter Notebook Diff and Merge tools
Package: wnpp Severity: wishlist Owner: Joseph Nahmias * Package name: nbdime Version : 2.1.0 Upstream Author : Jupyter Development Team * URL : https://nbdime.readthedocs.io/ * License : BSD Programming Lang: Python Description : Jupyter Notebook Diff and Merge tools nbdime provides tools for diffing and merging of Jupyter Notebooks. . * nbdiff - compare notebooks in a terminal-friendly way * nbmerge - three-way merge of notebooks with automatic conflict resolution * nbdiff-web - shows you a rich rendered diff of notebooks * nbmerge-web - gives you a web-based three-way merge tool for notebooks * nbshow - present a single notebook in a terminal-friendly way
Bug#995686: RFP: superset -- modern data exploration and visualization platform
Package: wnpp Severity: wishlist * Package name: superset Version : 1.3.1 Upstream Author : d...@superset.apache.org * URL : https://superset.apache.org/ * License : Apache-2.0 Programming Lang: Python Description : modern data exploration and visualization platform Superset is fast, lightweight, intuitive, and loaded with options that make it easy for users of all skill sets to explore and visualize their data, from simple line charts to highly detailed geospatial charts.
Bug#1001228: ITP: jupyter-kernel-test -- tool to test Jupyter kernels
Package: wnpp Severity: wishlist Owner: Joseph Nahmias X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org, j...@nahmias.net * Package name: jupyter-kernel-test Version : 0.4.2 Upstream Author : Jupyter Development Team * URL : https://github.com/jupyter/jupyter_kernel_test * License : BSD Programming Lang: Python Description : tool to test Jupyter kernels jupyter_kernel_test is a tool for testing Jupyter kernels. It tests kernels for successful code execution and conformance with the Jupyter Messaging Protocol (currently 5.0).
Bug#1010902: RFP: mlb-statsapi -- python module wrapping the MLB Statistics API
Package: wnpp Severity: wishlist X-Debbugs-Cc: j...@nahmias.net, t...@toddrob.com, debian-python@lists.debian.org * Package name: mlb-statsapi Version : 1.4.2 Upstream Author : Todd Roberts * URL : https://github.com/toddrob99/MLB-StatsAPI * License : GPL-3 Programming Lang: Python Description : python module wrapping the MLB Statistics API Good candidate for the Debian Python Team [DPT]
Bug#1011321: ITP: flask-jwt-extended -- Flask extension that provides JWT support
Package: wnpp Severity: wishlist Owner: Joseph Nahmias X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org, j...@nahmias.net, lily.gilb...@hey.com * Package name: flask-jwt-extended Version : 4.4.0 Upstream Author : Lily Acadia Gilbert * URL : https://github.com/vimalloc/flask-jwt-extended * License : Expat Programming Lang: Python Description : Flask extension that provides JWT support Flask-JWT-Extended not only adds support for using JSON Web Tokens (JWT) to Flask for protecting routes, but also many helpful (and optional) features built in to make working with JSON Web Tokens easier. These include: . * Adding custom claims to JSON Web Tokens * Automatic user loading (current_user). * Custom claims validation on received tokens * Refresh tokens * First class support for fresh tokens for making sensitive changes. * Token revoking/blocklisting * Storing tokens in cookies and CSRF protection Needed as a dependency of Flask-AppBuilder. I plan to maintain this as part of the Debian Python Team (DPT).
Bug#1016504: ITP: wtforms-components -- various additional fields, validators and widgets for WTForms
Package: wnpp Severity: wishlist Owner: Joseph Nahmias X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org, j...@nahmias.net, kon...@fastmonkeys.com * Package name: wtforms-components Version : 0.10.5 Upstream Author : Konsta Vesterinen * URL : https://github.com/kvesteri/wtforms-components * License : BSD Programming Lang: Python Description : various additional fields, validators and widgets for WTForms WTForms-Components provides enhanced versions of some WTForms HTML5 fields and some additional new fields and validatiors. These enhancements include: . * DateTimeField * IntegerField * SelectField * SelectMultipleField * ColorField * NumberRangeField * PassiveHiddenField * Read-only fields * DateRange validator * Email validator * If validator * Unique Validator
Bug#1016507: ITP: python-intervals -- tools for handling intervals (ranges of comparable objects) in python
Package: wnpp Severity: wishlist Owner: Joseph Nahmias X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org, j...@nahmias.net, kon...@fastmonkeys.com * Package name: python-intervals Version : 0.9.2 Upstream Author : Konsta Vesterinen * URL : https://github.com/kvesteri/intervals * License : BSD Programming Lang: Python Description : tools for handling intervals (ranges of comparable objects) in python This package provides objects, methods, constructors and functions for representing and manipulating mathematical intervals. Included are factory methods for creating intervals objects, comparison operators, set operators, and arithmetic functions.
Bug#1016460: ITP: wtforms-json -- smart json support for WTForms
Package: wnpp Severity: wishlist Owner: Joseph Nahmias X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org, kon...@fastmonkeys.com, j...@nahmias.net * Package name: wtforms-json Version : 0.3.5 Upstream Author : Konsta Vesterinen * URL : https://github.com/kvesteri/wtforms-json * License : BSD Programming Lang: Python Description : smart json support for WTForms WTForms-JSON is a WTForms extension for JSON data handling. It: . * Adds support for booleans (WTForms doesn’t know how to handle False boolean values) * Adds support for None type FormField values * Adds support for None type Field values * Support for patch data requests with patch_data Form property * Function for converting JSON data into dict that WTForms understands (flatten_json() function) This package is a dependency for superset. I plan to maintain this as part of the Debian Python Team (DPT).
Bug#1016462: ITP: wtforms-test -- unit test helpers for WTForms forms
Package: wnpp Severity: wishlist Owner: Joseph Nahmias X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org, j...@nahmias.net, kon...@fastmonkeys.com * Package name: wtforms-test Version : 0.1.1 Upstream Author : Konsta Vesterinen * URL : https://github.com/kvesteri/wtforms-test * License : BSD Programming Lang: Python Description : pytest helpers for WTForms WTForms-Test provides various pytest unittest helpers for testing WTForms based forms. Includes checks for a field's existence on a form, and various attributes on a field such as: validators, min/max length, description, optional/required, etc...
Bug#1016461: ITP: wtforms-alchemy -- Tools for creating WTForms forms from SQLAlchemy models
Package: wnpp Severity: wishlist Owner: Joseph Nahmias X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org, j...@nahmias.net, kon...@fastmonkeys.com * Package name: wtforms-alchemy Version : 0.18.0 Upstream Author : Konsta Vesterinen * URL : https://github.com/kvesteri/wtforms-alchemy * License : BSD Programming Lang: Python Description : Tools for creating WTForms forms from SQLAlchemy models WTForms-Alchemy provides a helper class that let you create a Form class from a SQLAlchemy model. It does not try to replace all the functionality of wtforms.ext.sqlalchemy, only the model_form function of wtforms.ext.sqlalchemy by a much better solution. Other functionality of .ext.sqlalchemy such as QuerySelectField and QuerySelectMultipleField can be used along with WTForms-Alchemy. . The benefits of WTForms-Alchemy ModelForm over wtforms.ext.sqlachemy’s model_form include: . * Provides explicit declaration of ModelForms (much easier to override certain columns) * Form generation supports Unique and NumberRange validators * Form inheritance support (along with form configuration inheritance) * Automatic SelectField type coercing based on underlying column type * By default uses wtforms_components SelectField for fields with choices. This field understands None values and renders nested datastructures as optgroups. * Provides better Unique validator * Supports custom user defined types as well as type decorators * Supports SQLAlchemy-Utils datatypes * Supports ModelForm model relations population * Smarter field exclusion * Smarter field conversion * Understands join table inheritance * Better configuration
Re: on the lack of a `python-` prefix for source packages
On Mon, Dec 12, 2022 at 04:36:53AM +, Scott Kitterman wrote: > On December 12, 2022 2:43:48 AM UTC, Sandro Tosi wrote: > >> >> My proposal as stated at the top is to start from now on to prepend > >> >> `python` to all NEW source packages in DPT, with the option to rename > >> >> existing packages at a later date. > >> >> > >> >> What are other team members' opinions on this? > >> > > >> > For packages that on contain a python module/extension, I think it's not > >> > horrible, but I don't see why it's better to diverge from upstream > >> > naming. > >> > >> I tend to agree with Sandro on for this use case. > > > >True, i was mostly referring to modules, as that's the most numerous > >type of packages we have > > > >> > For packages that contain or are primarily applications, I don't think > >> > it's a good idea. > >> > >> Ditto on that one, I don't feel having "python-supysonic" would be a > >> good naming scheme... > > > >please note that would be just for source packages, the user-facing > >ones can still be `supysonic` as that's what you expect to install > > > >On Sun, Dec 11, 2022 at 8:53 PM Scott Kitterman wrote: > >> What problem are you trying to solve? > > > >no problem specifically, i just feel that having a consistent scheme > >would benefit Debian and then team. > > If it's a case where multiple languages would likely have a package > with similar naming, I can see it's a good thing to be clear. When we > already don't use the same name as upstream in the binary (what > upstream has python3- in the package name?), I think there's value in > using the exact upstream name for the source package. I agree with Scott's reasoning here. Given that we prefix the binary packages with python3-, I strongly prefer to keep the source package name the same as upstream. I feel that way even for python modules and would vote against the requirement, but can understand and appreciate the other side of the argument. > I don't see how having an additional rule is helpful. I think every > rule we add makes it more complicated for new contributors, so we > should be careful to avoid adding new ones without good reason (and it > wouldn't hurt to revisit old ones and ditch things that have outlived > their usefulness). Agree here as well. Guidelines & reasonable defaults can be helpful for new contributors, but I really don't think we need a rule here -- whether or not it enshrines my (current) preference. > Scott K --Joe
