Re: suffix for packages with (optional?) Python extensions
On Fri, Jul 13, 2012 at 11:57:01 -0400, Scott Kitterman wrote:
1. python{3}-foo which is arch all and follows the current naming convention
of foo being the name you import. It would depend on the arch any python-foo-
ext package.
all - any package dependencies are often icky, if you want them to be
strictly versioned. Probably not a showstopper, but something to be
aware of.
Cheers,
Julien
--
Julien Cristau julien.cris...@logilab.fr
Logilab http://www.logilab.fr/
Informatique scientifique gestion de connaissances
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120716075759.ga7...@crater1.logilab.fr
Re: suffix for packages with (optional?) Python extensions
Julien Cristau julien.cris...@logilab.fr wrote:
On Fri, Jul 13, 2012 at 11:57:01 -0400, Scott Kitterman wrote:
1. python{3}-foo which is arch all and follows the current naming
convention
of foo being the name you import. It would depend on the arch any
python-foo-
ext package.
all - any package dependencies are often icky, if you want them to be
strictly versioned. Probably not a showstopper, but something to be
aware of.
Right now I'd just like to understand what is being proposed.
Scott K
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/063f9746-b6c6-40d9-bbea-637f1ae65...@email.android.com
Re: suffix for packages with (optional?) Python extensions
On Mon, 16 Jul 2012, Scott Kitterman wrote:
1. python{3}-foo which is arch all and follows the current naming
convention
of foo being the name you import. It would depend on the arch any
python-foo-
ext package.
all - any package dependencies are often icky, if you want them to be
strictly versioned. Probably not a showstopper, but something to be
aware of.
Right now I'd just like to understand what is being proposed.
look at any of mine python-* packages having corresponding -lib package.
e.g.
$ apt-get source python-nipy
...
$ grep -e Package: -e Architecture:
nipy-0.2.0\~rc2+git27-g7b9b5a5/debian/control
Package: python-nipy
Architecture: all
Package: python-nipy-lib
Architecture: any
Package: python-nipy-lib-dbg
Architecture: any
Package: python-nipy-doc
Architecture: all
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120716142418.gy21...@onerussian.com
Re: suffix for packages with (optional?) Python extensions
On Monday, July 16, 2012 10:24:18 AM Yaroslav Halchenko wrote:
On Mon, 16 Jul 2012, Scott Kitterman wrote:
1. python{3}-foo which is arch all and follows the current naming
convention
of foo being the name you import. It would depend on the arch any
python-foo-
ext package.
all - any package dependencies are often icky, if you want them to be
strictly versioned. Probably not a showstopper, but something to be
aware of.
Right now I'd just like to understand what is being proposed.
look at any of mine python-* packages having corresponding -lib package.
e.g.
$ apt-get source python-nipy
...
$ grep -e Package: -e Architecture:
nipy-0.2.0\~rc2+git27-g7b9b5a5/debian/control Package: python-nipy
Architecture: all
Package: python-nipy-lib
Architecture: any
Package: python-nipy-lib-dbg
Architecture: any
Package: python-nipy-doc
Architecture: all
OK. python-nipy depends on python-nipy-lib. Makes sense.
Package: python-nipy-lib
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}
Provides: ${python:Provides}
XB-Python-Version: ${python:Versions}
Description: Analysis of structural and functional neuroimaging data
NiPy is a Python-based framework for the analysis of structural and
functional neuroimaging data.
.
This package provides architecture-dependent builds of the libraries.
Is python-nipy-lib useful on it's own? It seems odd to me that it doesn't at
least Suggest python-nipy.
Scott K
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2045675.bODldYHci7@scott-latitude-e6320
Re: suffix for packages with (optional?) Python extensions
On Mon, 16 Jul 2012, Scott Kitterman wrote: OK. python-nipy depends on python-nipy-lib. Makes sense. Is python-nipy-lib useful on it's own? nope -- moreover it might be somewhat detrimental -- module might appear to be installed while only extensions are there. That is the only disadvantage of such an approach. It seems odd to me that it doesn't at least Suggest python-nipy. and that is where I think circular dependencies are coming -- although I do not remember details and why I haven't had Suggest -- it clearly worth adding -- may be it is ok now ;-) ? -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120716150659.gd21...@onerussian.com
Re: suffix for packages with (optional?) Python extensions
On Monday, July 16, 2012 11:06:59 AM Yaroslav Halchenko wrote: On Mon, 16 Jul 2012, Scott Kitterman wrote: OK. python-nipy depends on python-nipy-lib. Makes sense. Is python-nipy-lib useful on it's own? nope -- moreover it might be somewhat detrimental -- module might appear to be installed while only extensions are there. That is the only disadvantage of such an approach. It seems odd to me that it doesn't at least Suggest python-nipy. and that is where I think circular dependencies are coming -- although I do not remember details and why I haven't had Suggest -- it clearly worth adding -- may be it is ok now ;-) ? I think it is worth getting consensus on how this should be done before you make a change. I think at least suggests, but I think recommends is better if it doesn't behave as a dependency loop. I haven't looked into how this gets handled yet. Anyone? Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1347516.j6B7HhzdZl@scott-latitude-e6320
Re: suffix for packages with (optional?) Python extensions
On Mon, Jul 16, 2012 at 11:37:17 -0400, Scott Kitterman wrote: I think at least suggests, but I think recommends is better if it doesn't behave as a dependency loop. I haven't looked into how this gets handled yet. Anyone? Recommends should be fine AFAIK, since they don't impose any unpack/configuration ordering on the package manager. Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120716155806.gf7...@crater1.logilab.fr
Re: suffix for packages with (optional?) Python extensions
Barry Warsaw ba...@python.org writes: On Jul 12, 2012, at 09:00 PM, Piotr Ożarowski wrote: I use -ext (python-sqlalchemy-ext) but now I see that there are also -accel (python-reportlab-accel) and -lib (python-guppy-lib) I suppose I have a mild preference for the -ext shade of bikeshed. Python terminology for these is already “extension”, so that lends weight to the ‘-ext’ suffix. ‘-lib’ is confusing because a ‘python-foo’ package is generally a library (of Python code) anyway. The packages under discussion here are distinct from normal Python libraries. ‘-accel’ is specific to only one kind of extension (those that are for the purpose of increasing speed), and doesn't describe all Python extensions (e.g. those that, regardless of speed, are for the purpose of interfacing with non-Python code). So I think ‘-ext’ is the current winner on the basis of existing terminology. -- \ “As the most participatory form of mass speech yet developed, | `\the Internet deserves the highest protection from governmental | _o__) intrusion.” —U.S. District Court Judge Dalzell | Ben Finney pgpCla8zoP850.pgp Description: PGP signature
Re: suffix for packages with (optional?) Python extensions
On Jul 12, 2012, at 09:00 PM, Piotr Ożarowski wrote: can we agree on a common suffix for such¹ packages and add a suggestion to Debian Python Policy? +1 I use -ext (python-sqlalchemy-ext) but now I see that there are also -accel (python-reportlab-accel) and -lib (python-guppy-lib) I suppose I have a mild preference for the -ext shade of bikeshed. -Barry signature.asc Description: PGP signature
Re: suffix for packages with (optional?) Python extensions
On Friday, July 13, 2012 11:48:57 AM Barry Warsaw wrote:
On Jul 12, 2012, at 09:00 PM, Piotr Ożarowski wrote:
can we agree on a common suffix for such¹ packages and add a suggestion
to Debian Python Policy?
+1
I use -ext (python-sqlalchemy-ext) but now I see that there are also
-accel (python-reportlab-accel) and -lib (python-guppy-lib)
I suppose I have a mild preference for the -ext shade of bikeshed.
To make sure I understand this ...
For packages with a large mix of arch all Python and arch any extensions, they
could be split into two binaries:
1. python{3}-foo which is arch all and follows the current naming convention
of foo being the name you import. It would depend on the arch any python-foo-
ext package.
2. python{3}-foo-ext which is arch any and Suggests/Recommends (not sure
which) python{3}-foo.
Is that right?
How would this work for packages where the extension is not built on all
architectures?
Scott K
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1366059.DrSicR9nDd@scott-latitude-e6320
suffix for packages with (optional?) Python extensions
[Yaroslav Halchenko, 2012-07-11] since our works were mentioned ;) -- yes, we generally split out python extensions (and anything else arch-dep) into python-*-lib packages can we agree on a common suffix for such¹ packages and add a suggestion to Debian Python Policy? I use -ext (python-sqlalchemy-ext) but now I see that there are also -accel (python-reportlab-accel) and -lib (python-guppy-lib) [¹] packages with split out (optional?) Python extensions -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 signature.asc Description: Digital signature
Re: suffix for packages with (optional?) Python extensions
Hi Piotr (2012.07.13_05:00:45_+0200) can we agree on a common suffix for such¹ packages and add a suggestion to Debian Python Policy? I use -ext (python-sqlalchemy-ext) but now I see that there are also -accel (python-reportlab-accel) and -lib (python-guppy-lib) I also know of a -helpers (veusz-helpers) +1 to some standardisation. Propose a policy patch? SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120713032033.gd1...@bach.rivera.co.za
Re: suffix for packages with (optional?) Python extensions
can we agree on a common suffix for such¹ packages and add a suggestion
to Debian Python Policy?
I use -ext (python-sqlalchemy-ext) but now I see that there are also
-accel (python-reportlab-accel) and -lib (python-guppy-lib)
good idea... Now I somewhat like -ext more than -lib -- it is more Pythonic --
but I guess I am the biggest abuser with the -lib (codespeak is not mine).
Also -lib might actually be more factual -- it is not necessarily native
Pythonic extensions which would be provided there but might be other .so's
(native dynamic libraries etc -- just look inside python-numpy since
python-numpy-ext is apparently a transitional package since 2007 I found on my
drive ;) )
$ dpkg -l python-*-{lib,ext,accel}
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++--=-=-==
ii python-brian-lib 1.3.1-1+b1amd64 simulator for
spiking neural networks -- extensions
ii python-bson-ext 2.2-2 amd64 C-coded
extension to the python-bson package
un python-codespeak-lib none (no
description available)
ii python-dipy-lib 0.5.0-3 amd64 toolbox for
analysis of MR diffusion imaging data -- e
un python-guppy-lib none (no
description available)
ii python-mlpy-lib 2.2.0~dfsg1-2+b1 amd64 low-level
implementations and bindings for mlpy
ii python-mvpa-lib 0.4.8-1 amd64 low-level
implementations and bindings for PyMVPA
ii python-mvpa2-lib 2.1.0-1 amd64 low-level
implementations and bindings for PyMVPA v. 2
ii python-numpy-ext 1:1.3.0-3 all NumPy adds a
fast array facility to the Python languag
ii python-pandas-lib0.8.0-1 amd64 low-level
implementations and bindings for pandas
ii python-pymongo-ext 2.2-2 amd64 C-coded
extension to the python-pymongo package
ii python-reportlab-accel 2.5-1.1 amd64 C coded
extension accelerator for the ReportLab Toolki
un python-scikits-learn-lib none (no
description available)
ii python-skimage-lib 0.6-1 amd64 Optimized
low-level algorithms for scikits-image
ii python-sklearn-lib 0.11.0-2 amd64 low-level
implementations and bindings for scikit-lear
ii python-sqlalchemy-ext0.7.8-1 amd64 SQL toolkit
and Object Relational Mapper for Python -
ii python-statsmodels-lib 0.4.0-2 amd64 low-level
implementations and bindings for statsmodels
On Thu, 12 Jul 2012, Piotr Ożarowski wrote:
[Yaroslav Halchenko, 2012-07-11]
since our works were mentioned ;) -- yes, we generally split out python
extensions (and anything else arch-dep) into python-*-lib packages
[¹] packages with split out (optional?) Python extensions
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120713033030.gu21...@onerussian.com
