[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The new python policy and packaging

Le jeu 27 juillet 2006 23:20, Manoj Srivastava a écrit :
> On Thu, 27 Jul 2006 14:15:47 -0500, Joe Wreschnig 
<piman@sacredchao.net> said:

> > Your confusion is due to an incorrect distinction. .py and .so
> > files are both modules; .so files are "extension modules" and .py
> > files are "pure Python modules". When the word "module" is used
> > alone it always refers to both.
>         Then please explain section 2.2:
>  "Public modules should be packaged with a name of python-foo, where
>   foo is the name of the module. <snip> This requirement also applies
>   to extension modules; binaries for all the supported Python
> versions should be included in a single package. "
>         The wording implies that Public modules are distinct from
>  extension modules (since something stated for public modules
>  also applies to extension modules. Policy otherwise states public vs
>  private and pure modules vs extension modules are orthogonal, so
>  there is an inconsistency here.

public modules are modules that live 
in /usr/{lib,share}/python$VERSION/site-packages/ and that anybody 
can 'import' in a python program

whereas python private modules/extensions are modules that are used 
internally by a program, but that it does not intend to share with 
others. it's completely orthogonal to beeing pure python or a C 

wording in the python folks is often module (like in pure python module) 
vs. extension (like C extension). I suppose it's sometimes hard to 
write a policy with a wording a bit different of what is often used.

*I* personnaly prefer module/extension terminology, as it's nearer to 
what it is. a module is implicitely written in the language, whereas an 
extension cannot, hence is written as an C library. but this is 

> > Because then applications using the default python
> > (/usr/bin/python) can access it, and that will be true for versions
> > beyond 2.4. The versioned names are not appropriate for packages
> > using the default version.
>         Why do my packages need to change the dependencies, then?
>  Because when the default changes to 2.5, the dependency would have
>  to change yet again, for no changes in the package itself.

yes but the package would only need a rebuild (aka binNMU) which is the 
whole point of the policy: make the python transition be a big run of 
binNMU for arch:any packages (as per definition, arch:all packages are 
not binNMUable)

and if you use dh_* thingies, it achieves that. I suppose it's also 
doable without them though.

>         Oh, I see. Say, there is an extension that implements a very
>  standard API for framework bar, which is packaged in package
>  bar. If this extension modules is used by a non-version-specific
>  script, the script can just import module foo, and not care that it
>  lives in a version specific dir.
>         Expanding on that thought, suppose I have python-foo version
>  1.0 that has been compiled with python 2.3. If the script uses
>  /usr/bin/python2.4, it won't be able to import my module --- unless
>  it asks for and gets a python2.4-foo. So, if the script uses a non
>  default version of python, or the extension module was compiled for
> a non-default version of python, I must provide pythonX.Y-fooin case
> someone somewhere has a script calling a specific version of python.
>         There is no actual harm in always providing pythonX.Y-foo for
>  all extentsion module packages (for all x.y supported and shipped
>  with the package).

that's it.

·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

Attachment: pgptOcFqjyec1.pgp
Description: PGP signature

Reply to: