Re: suffix for packages with (optional?) Python extensions

2012-07-16 Thread Julien Cristau
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  
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

2012-07-16 Thread Scott Kitterman
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

2012-07-16 Thread Yaroslav Halchenko

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

2012-07-16 Thread Scott Kitterman
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

2012-07-16 Thread Yaroslav Halchenko

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

2012-07-16 Thread Scott Kitterman


Julien Cristau  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

2012-07-16 Thread Julien Cristau
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  
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

2012-07-14 Thread Ben Finney
Barry Warsaw  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

2012-07-13 Thread Scott Kitterman
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



Re: suffix for packages with (optional?) Python extensions

2012-07-13 Thread Barry Warsaw
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

2012-07-12 Thread Yaroslav Halchenko
> 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   (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   (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   (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



Re: suffix for packages with (optional?) Python extensions

2012-07-12 Thread Stefano Rivera
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



suffix for packages with (optional?) Python extensions

2012-07-12 Thread Piotr Ożarowski
[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