Re: Dealing with flit -- a simplified packaging of python modules
On Fri, Sep 18, 2015, at 11:56 PM, Julien Puydt wrote: > here is a new way to package modules for Python: > https://github.com/takluyver/flit > > It means that something packaged using it doesn't use a setup.py or some > such, but a flit.ini ; see for example: > https://github.com/jupyter/testpath > > I'm not sure how to package something like this (and testpath is a > depends for IPython's tests), so I think asking here is better. By the way, I am also upstream for flit, and I'm prepared to help build some tooling to use it for distro packaging. I know it will cause some inconvenience in the short term because there's infrastructure around setup.py packaging, but ultimately I think that having declarative metadata should be an advantage. Thomas
Re: Dealing with flit -- a simplified packaging of python modules
Hi, Le samedi 19 sept. 2015 à 00:35:49 (-0700), Thomas Kluyver a écrit : > On Fri, Sep 18, 2015, at 11:56 PM, Julien Puydt wrote: > > here is a new way to package modules for Python: > > https://github.com/takluyver/flit > > > > It means that something packaged using it doesn't use a setup.py or some > > such, but a flit.ini ; see for example: > > https://github.com/jupyter/testpath > > > > I'm not sure how to package something like this (and testpath is a > > depends for IPython's tests), so I think asking here is better. > > By the way, I am also upstream for flit, and I'm prepared to help build > some tooling to use it for distro packaging. I know it will cause some > inconvenience in the short term because there's infrastructure around > setup.py packaging, but ultimately I think that having declarative > metadata should be an advantage. > > Thomas > Yes, you're also upstream for ptyprocess and terminado :-P I have nothing against declarative -- it's just that I suspect we will need something like a --buildsystem=flit or some such, and I have no clue how to do something like this... Snark on #debian-python
Re: Dealing with flit -- a simplified packaging of python modules
On Sat, Sep 19, 2015, at 01:05 AM, Julien Puydt wrote: > Yes, you're also upstream for ptyprocess and terminado :-P Guilty as charged ;-) I work for Jupyter/IPython, so there are several dependencies from that that I'm responsible for. > I have nothing against declarative -- it's just that I suspect we will > need something like a --buildsystem=flit or some such, and I have no > clue how to do something like this I don't know how to define a new buildsystem either. For the first package, I hope that we can do without that, at the cost of a longer Debian/rules file that specifies more stuff explicitly, and then work out what bits of that can be abstracted into tooling. Thomas
RFS: traitlets -- Lightweight Traits-like package
Hi, * Package name: traitlets Version : 4.0.0 Upstream Author : IPython Development Team * URL : https://github.com/ipython/traitlets * License : BSD-3-clause Programming Lang: Python Description : Lightweight Traits-like package A lightweight pure-Python derivative of Enthought Traits, used for configuring Python objects. . It powers the config system of IPython and Jupyter. It is one of the last depends before the newer IPython can be packaged (there is still testpath). Cheers, Snark on #debian-python
Re: RFS: traitlets -- Lightweight Traits-like package
Hi, Le samedi 19 sept. 2015 à 15:29:09 (+0200), Julien Puydt a écrit : > Hi, > > * Package name: traitlets > Version : 4.0.0 > Upstream Author : IPython Development Team > * URL : https://github.com/ipython/traitlets > * License : BSD-3-clause > Programming Lang: Python > Description : Lightweight Traits-like package > A lightweight pure-Python derivative of Enthought Traits, used > for configuring Python objects. > . > It powers the config system of IPython and Jupyter. > > It is one of the last depends before the newer IPython can be packaged > (there is still testpath). > I forgot to mention that I packaged it here: Vcs-Git: git://anonscm.debian.org/python-modules/packages/traitlets.git Vcs-Browser: http://anonscm.debian.org/cgit/python-modules/packages/traitlets.git Snark on #debian-python
Bug#799470: ITP: jupyter-core -- Core common functionality of Jupyter projects
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-python@lists.debian.org * Package name: jupyter-core Version : 4.0.6 Upstream Author : Jupyter Development Team * URL : https://github.com/jupyter/jupyter_core * License : BSD-3-clause Programming Lang: Python Description : Core common functionality of Jupyter projects This package contains the base framework (application classes and configurations) for the rest of the Jupyter projects ; it doesn't do much by itself. Cheers, Snark on #debian-python
Re: Dealing with flit -- a simplified packaging of python modules
On Sep 19, 2015, at 12:35 AM, Thomas Kluyver wrote: >By the way, I am also upstream for flit, and I'm prepared to help build >some tooling to use it for distro packaging. I know it will cause some >inconvenience in the short term because there's infrastructure around >setup.py packaging, but ultimately I think that having declarative >metadata should be an advantage. There have been countless attempts at moving the Python packaging infrastructure to a declarative syntax over the years. I remember talking to Tarek at a Pycon *many* years ago about this. Maybe this time it'll catch on. :) flit doesn't build sdists, so I guess the current toolchain which starts with .orig.tar.gz won't work with flitted packages. The README says: "People may also want a traditional sdist for other reasons, such as Linux distro packaging. I hope that these problems will diminsh over time." I'm not sure which problem you hope will diminish! People wanting traditional sdists, the problem of Linux distro packaging or needing sdists for downstream consumers like Debian. OTOH, as wheels get more popular for upstream package distributions, I do think we need a good story for turning wheels into debs. There's some work ongoing to turn debs back into wheels: https://github.com/paulproteus/dirtbike Cheers, -Barry
