Re: Python and Emacs

[Jonne Itkonen]

On 21 May 2002, Ron Johnson wrote:

> On Tue, 2002-05-21 at 15:27, Jérôme Marant wrote:
> [snip]
> >   I'm a bit annoyed with Emacs when editing Python programs because
> >   Emacs always replaces TABs with spaces ; this wouldn't bother me if
> >   Emacs was the only editor in the world. But when you share programs
> >   with others, it is better to have real TABs instead of spaces.
>
> This is amusing: I think exactly the opposite, since I indent
> every 4 columns, and if \t were set to 4, then when less'ing
> the file, it would look differently that it does in the editor...

(Skip the next chapter to read something useful...)

And I again opposite to your opinion. If everybody uses tab to indent,
then everyone can set his or her environment to render that tab with
as many spaces as necessary, _or_ when using proportional fonts, as
long an empty space as needed. I really don't understand why one would
like to use spaces to indent, but because of his or her inability to
configure the programming environment used, or in the case of emacs, the
impossibility of configuration (yes, I use vim and I'm happy with it,
though emacs has these nice environments like oo-browser etc).

And now something useful: less has an option '-x' which tells less how
many spaces to use when rendering tabs. The correct and the default value
is 8, but the option is available, and everybody is happy.

   Jonne


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Python and Emacs

[Ron Johnson]

On Wed, 2002-05-22 at 01:40, Jonne Itkonen wrote:
> On 21 May 2002, Ron Johnson wrote:
> 
> > On Tue, 2002-05-21 at 15:27, Jérôme Marant wrote:
[snip] 
> And now something useful: less has an option '-x' which tells less how
> many spaces to use when rendering tabs. The correct and the default value
> is 8, but the option is available, and everybody is happy.

That _is_ useful!!
 
-- 
+-+
| Ron Johnson, Jr.Home: [EMAIL PROTECTED] |
| Jefferson, LA  USA  http://ronandheather.dhs.org:81 |
| |
| "I have created a government of whirled peas..."|
|   Maharishi Mahesh Yogi, 12-May-2002,   |
!   CNN, Larry King Live  |
+-+


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Python and Emacs

[Luca - De Whiskey's - De Vitis]

On Tue, May 21, 2002 at 11:21:44PM +0200, J?r?me Marant wrote:
> > Of course, we all know that using tabs in Python code is Evil. :-)
> 
>   Sure. Now, you make me think that sharing code with Vimers is
>   Evil too. I wouldn't need such a trick ;-)

If the problem is that `Vimers' do not use spaces for indentation, suggests
the them to add the following to their ~/.vimrc :

--- cut ---
augroup Python
au!
autocmd BufRead *.py set expandtab softtabstop=4 shiftwidth=4 tabstop=4
augroup END
--- /cut ---

Tell them to type :help to understand what this configuration will do.

I'm not a vim wizard, but this should work.

ciao,
-- 
Luca - De Whiskey's - De Vitis  | Elegant or ugly code as well
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have
Luca, a wannabe ``Good guy''.   | something in common: they
local LANG="[EMAIL PROTECTED]" | don't depend on the 
language.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Python and Emacs

[Florent Rougon]

Jonne Itkonen <[EMAIL PROTECTED]> wrote:

> And I again opposite to your opinion. If everybody uses tab to indent,
> then everyone can set his or her environment to render that tab with
> as many spaces as necessary, _or_ when using proportional fonts, as
> long an empty space as needed. I really don't understand why one would

That argument is not void, but using spaces only to indent ensures that
everyone writes code that has a reasonably depth (i.e., doesn't consist
of 1 function whose code is 200 columns wide). If someone is using tabs
with a length of e.g. 2 spaces, he will presumably write awful code as
I just described.

> like to use spaces to indent, but because of his or her inability to
> configure the programming environment used, or in the case of emacs, the
> impossibility of configuration (yes, I use vim and I'm happy with it,

Er, WTF are you talking about ?

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Packaging, supporting both 2.1 and 2.2

[Moshe Zadka]

[please CC me, I'm not on the list]
Hypothetical situation:
Source package: contains foo.py (python module, works with every python
version under the sun) and foo (a script whose first line is 
"import foo"). I want to properly support people who want 2.1 and 2.2.
There are several audiences here:

1. People who want to use "foo"
2. People who want to develop against "foo.py"

Multiplied by

1. People who have python2.1 only 
2. People who have python2.2 only 
3. People who have python2.1 and python2.2

I'm generating a python2.1-foo and python2.2-foo containing foo.py, as
per draft policy. 

Here are alternatives for where to put /usr/bin/foo:

1. in python2.1-foo and python2.2-foo, in /usr/bin/foo, making them conflict
   Pros: easy enough for me.
   Cons: people who develop against foo.py cannot check for 2.1 and 2.2
 compatibility without lots of pain

2. in py2.1-foo and py2.2-foo, as /usr/bin/foo2.{1,2}, manage symlinks
   via alternatives
   Pros: no conflicts
   Cons: high maintainence: every script added to the package must
 be echoed in my postinst/prerm, priority must take into account
 debian default version

3. in py2.1-foo-bin and py.2.2-foo-bin, which depend on an appropriate
   py2.x-foo package, and Provide: Replace: and Conflict: py-foo-bin
   Pros: easy for me, no conflicts of python modules
   Cons: people who want some users to run foo2.1 and some to run foo2.2
 (perhaps foo reads a config file, and the users want to program
 the config file in the appropriate version of python, or as
 in my case, foo keeps state in pickles) cannot

There are, of course, lots of variants possible on these two.
My question is two-fold:

a. Was anyone in this situation? What did you do?
b. Should we document a best current practice in the now-being-written
   developer reference? next version of draft policy?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Packaging, supporting both 2.1 and 2.2

[Bastian Kleineidam]

On Wed, May 22, 2002 at 11:01:14AM -, Moshe Zadka wrote:
> [please CC me, I'm not on the list]
NP.

> Hypothetical situation:
> Source package: contains foo.py (python module, works with every python
> version under the sun) and foo (a script whose first line is 
> "import foo"). I want to properly support people who want 2.1 and 2.2.
There is a package called python-central which allows version-independent
packages.
http://people.debian.org/~calvin/python-central/
Precondition: you have a "pure" pyhthon module, no C-compiled Extension.

If you do not want to wait until python-central is uploaded, you can do
something like this:
a) python2.1-foo: python foo.py module for 2.1
b) python2.2-foo: python foo.py module for 2.2
c) python-foo: /usr/bin/foo binary with #!/usr/bin/python
   Depends: python2.1-foo | python2.2-foo

Greetings, Bastian


pgp5gVYOcFWHo.pgp
Description: PGP signature

Re: Packaging, supporting both 2.1 and 2.2

[Moshe Zadka]

On Wed, 22 May 2002, Bastian Kleineidam <[EMAIL PROTECTED]> wrote:

> There is a package called python-central which allows version-independent
> packages.
> http://people.debian.org/~calvin/python-central/
> Precondition: you have a "pure" pyhthon module, no C-compiled Extension.

Sorry, the situation in the non-hypothetical case does involve an
extension.

> a) python2.1-foo: python foo.py module for 2.1
> b) python2.2-foo: python foo.py module for 2.2
> c) python-foo: /usr/bin/foo binary with #!/usr/bin/python
>Depends: python2.1-foo | python2.2-foo

Doesn't work.
What if the user installed python2.2-foo but /usr/bin/python
is /usr/bin/python2.1, or vice versa?
If this is what python-central does, then python-central, I'm afraid,
has a bug...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Packaging, supporting both 2.1 and 2.2

[Bastian Kleineidam]

Hi Moshe,

On Wed, May 22, 2002 at 12:09:11PM -, Moshe Zadka wrote:
> > a) python2.1-foo: python foo.py module for 2.1
Depends: python2.1

> > b) python2.2-foo: python foo.py module for 2.2
Depends: python2.2

> > c) python-foo: /usr/bin/foo binary with #!/usr/bin/python
> >Depends: python2.1-foo | python2.2-foo
> 
> Doesn't work.
> What if the user installed python2.2-foo but /usr/bin/python
> is /usr/bin/python2.1, or vice versa?
Ah, I forgot: python2.x-foo has to depend on python2.x package.

Now the only catch is if you have both python2.1-foo and python2.2-foo
installed (and therefore have both python2.1 and python2.2), then
/usr/bin/foo will always call the default /usr/bin/python (currently
this is python2.1). But this is ok, since foo is version independant.


> If this is what python-central does, then python-central, I'm afraid,
> has a bug...
python-central does not support binaries in /usr/bin, it only supports
pure Python modules which go into /usr/lib/python/site-packages.


Greetings, Bastian


pgp1BFyEGgrQW.pgp
Description: PGP signature

Re: Packaging, supporting both 2.1 and 2.2

[Chris Lawrence]

On May 22, Moshe Zadka wrote:
> Doesn't work.
> What if the user installed python2.2-foo but /usr/bin/python
> is /usr/bin/python2.1, or vice versa?
> If this is what python-central does, then python-central, I'm afraid,
> has a bug...

Under Debian's Python policy, /usr/bin/python is guaranteed to be
Python 2.1 for woody.


Chris
-- 
Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Python and Emacs

[dman]

On Wed, May 22, 2002 at 10:46:59AM +0200, Luca - De Whiskey's - De Vitis wrote:
| On Tue, May 21, 2002 at 11:21:44PM +0200, J?r?me Marant wrote:
| > > Of course, we all know that using tabs in Python code is Evil. :-)
| > 
| >   Sure. Now, you make me think that sharing code with Vimers is
| >   Evil too. I wouldn't need such a trick ;-)
| 
| If the problem is that `Vimers' do not use spaces for indentation, suggests
| the them to add the following to their ~/.vimrc :
| 
| --- cut ---
| augroup Python
| au!
| autocmd BufRead *.py set expandtab softtabstop=4 shiftwidth=4 tabstop=4
| augroup END
| --- /cut ---
| 
| Tell them to type :help to understand what this configuration will do.
| 
| I'm not a vim wizard, but this should work.

It will work, but I disagree with changing the 'tabstop' variable.

Try catting your code directly to a line printer.  It will use 8
spaces per tab, and that will mess up things.  Another problem is the
width of a line.  It is really horrible to try and read code that is
too wide to fit on your screen or that wraps around.  Following the
"lowest common denominator" ensures that your code is nicely readable
in any common environment.

-D

-- 

But As for me and my household, we will serve the Lord.
Joshua 24:15
 
GnuPG key : http://dman.ddts.net/~dman/public_key.gpg



pgpyJ1oTkmm8d.pgp
Description: PGP signature

Re: Packaging, supporting both 2.1 and 2.2

[Moshe Zadka]

On Wed, 22 May 2002, Bastian Kleineidam <[EMAIL PROTECTED]> wrote:

> On Wed, May 22, 2002 at 12:09:11PM -, Moshe Zadka wrote:
> > > a) python2.1-foo: python foo.py module for 2.1
> Depends: python2.1
> 
> > > b) python2.2-foo: python foo.py module for 2.2
> Depends: python2.2

Of course
You do not understand me.

> > > c) python-foo: /usr/bin/foo binary with #!/usr/bin/python
> > >Depends: python2.1-foo | python2.2-foo
> >=20
> > Doesn't work.
> > What if the user installed python2.2-foo but /usr/bin/python
> > is /usr/bin/python2.1, or vice versa?
> Ah, I forgot: python2.x-foo has to depend on python2.x package.

So what?

Situation:
python2.1, python2.2, python2.2-foo and python-foo are all installed.
python2.1 is the default.
All dependancies are resolved, right?

#!/usr/bin/python
import foo

equivalent to 

#!/usr/bin/python2.1
import foo

But, alas, python2.1's search path *does not contain* foo.py
ImportError: foo not found.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Packaging, supporting both 2.1 and 2.2

[Matthias Klose]

Moshe Zadka writes:
> On Wed, 22 May 2002, Bastian Kleineidam <[EMAIL PROTECTED]> wrote:
> 
> > On Wed, May 22, 2002 at 12:09:11PM -, Moshe Zadka wrote:
> > > > a) python2.1-foo: python foo.py module for 2.1
> > Depends: python2.1
> > 
> > > > b) python2.2-foo: python foo.py module for 2.2
> > Depends: python2.2
> 
> Of course
> You do not understand me.
> 
> > > > c) python-foo: /usr/bin/foo binary with #!/usr/bin/python
> > > >Depends: python2.1-foo | python2.2-foo
> > >=20
> > > Doesn't work.
> > > What if the user installed python2.2-foo but /usr/bin/python
> > > is /usr/bin/python2.1, or vice versa?
> > Ah, I forgot: python2.x-foo has to depend on python2.x package.
> 
> So what?
> 
> Situation:
> python2.1, python2.2, python2.2-foo and python-foo are all installed.
> python2.1 is the default.
> All dependancies are resolved, right?
> 
> #!/usr/bin/python
> import foo
> 
> equivalent to 
> 
> #!/usr/bin/python2.1
> import foo
> 
> But, alas, python2.1's search path *does not contain* foo.py
> ImportError: foo not found.

wrong. python-foo depends on python2.1-foo, so foo is found.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Packaging, supporting both 2.1 and 2.2

[Moshe Zadka]

On Wed, 22 May 2002, Matthias Klose <[EMAIL PROTECTED]> wrote:

> > > > > c) python-foo: /usr/bin/foo binary with #!/usr/bin/python
> > > > >Depends: python2.1-foo | python2.2-foo
^ that's an or sign, right

> > python2.1, python2.2, python2.2-foo and python-foo are all installed.

(notice the lack of python2.1-foo)

> > python2.1 is the default.
> > All dependancies are resolved, right?

right?

> wrong. python-foo depends on python2.1-foo, so foo is found.

it doesn't, and it isn't.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Python and Emacs

[Luca - De Whiskey's - De Vitis]

On Wed, May 22, 2002 at 08:38:26AM -0500, dman wrote:
> | --- cut ---
> | augroup Python
> | au!
> | autocmd BufRead *.py set expandtab softtabstop=4 shiftwidth=4 tabstop=4
> | augroup END
> | --- /cut ---

> It will work, but I disagree with changing the 'tabstop' variable.
> 
> Try catting your code directly to a line printer.  It will use 8
> spaces per tab, and that will mess up things.  Another problem is the

No, it will not. This configuration actually uses space (4 in this case)
instead of a single tab. It only gives the user the feeling he is using tab,
while he is not.

Try the :help for 'expandtab' 'softtabstop'.

ciao,
-- 
Luca - De Whiskey's - De Vitis  | Elegant or ugly code as well
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have
Luca, a wannabe ``Good guy''.   | something in common: they
local LANG="[EMAIL PROTECTED]" | don't depend on the 
language.


pgpbjdf2T8d6k.pgp
Description: PGP signature

Re: Packaging, supporting both 2.1 and 2.2

[Bastian Kleineidam]

On Wed, May 22, 2002 at 01:09:02PM -, Moshe Zadka wrote:
> Situation:
> python2.1, python2.2, python2.2-foo and python-foo are all installed.
> python2.1 is the default.
> All dependancies are resolved, right?
> 
> #!/usr/bin/python
> import foo
> 
> equivalent to 
> 
> #!/usr/bin/python2.1
> import foo
> 
> But, alas, python2.1's search path *does not contain* foo.py
> ImportError: foo not found.
Ok, thats a problem. There is no way out for this; you'd have to
have two binaries.

To sum it up, I would do the following:

Provide library packages: python2.1-foo, python2.2-foo.
Provide *one* binary package for the default python version:
python-foo (or just foo).

This way you have the best of all worlds: developers using the
library can test and code for all versions they like.
People who use the binary install it and run it. Remember that most
users dont care about versions, they install and click yes for any
dependencies.


Greetings from Munich,

Bastian



pgpiynNHuxFJj.pgp
Description: PGP signature

Re: Python and Emacs

[dman]

On Wed, May 22, 2002 at 05:50:10PM +0200, Luca - De Whiskey's - De Vitis wrote:
| On Wed, May 22, 2002 at 08:38:26AM -0500, dman wrote:
| > | --- cut ---
| > | augroup Python
| > | au!
| > | autocmd BufRead *.py set expandtab softtabstop=4 shiftwidth=4 
tabstop=4
| > | augroup END
| > | --- /cut ---
| 
| > It will work, but I disagree with changing the 'tabstop' variable.
| > 
| > Try catting your code directly to a line printer.  It will use 8
| > spaces per tab, and that will mess up things.  Another problem is the
| 
| No, it will not. This configuration actually uses space (4 in this case)
| instead of a single tab. It only gives the user the feeling he is using tab,
| while he is not.

Right.  It must have been too early in the morning ... I meant if you
use real tab characters and just fiddle with tabstop you are bound to
cause problems (which is why I always leave 'ts' set to 8). 

| Try the :help for 'expandtab' 'softtabstop'.

They are wonderful options!  Just don't set 'et' for Makefiles!  (also
check out the 'list' and 'listchars' options -- it really helps to
actually _see_ the tab characters in a different way than space
characters)

-D

-- 

A perverse man stirs up dissension,
and a gossip separates close friends.
Proverbs 16:28
 
GnuPG key : http://dman.ddts.net/~dman/public_key.gpg



pgpT62v5JeTV9.pgp
Description: PGP signature

Re: Packaging, supporting both 2.1 and 2.2

[Moshe Zadka]

On Wed, 22 May 2002, Bastian Kleineidam <[EMAIL PROTECTED]> wrote:

> Ok, thats a problem. There is no way out for this; you'd have to
> have two binaries.

Yes, I know I'll have to have two binaries.

> Provide library packages: python2.1-foo, python2.2-foo.
> Provide *one* binary package for the default python version:
> python-foo (or just foo).

This isn't an option.
I think I know my users. I do have users which need python2.1, and I do
have users which need python2.2. I do not want to force either to 
"go install from source".

I can have

python2.1-foo, python2.2-foo, python2.1-foo-bin, python2.2-foo-bin
(with the obvious contents, and python2.x-foo-bin conflict with each
other)
and python-foo Depends: python2.1-foo-bin | python2.2-foo-bin
so a user installing python-foo will get python2.1-foo-bin by default
(because it is first in the or rule)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Python and Emacs

[Juha Autero]

Jonne Itkonen <[EMAIL PROTECTED]> writes:

> On 21 May 2002, Ron Johnson wrote:
>
>> This is amusing: I think exactly the opposite, since I indent
>> every 4 columns, and if \t were set to 4, then when less'ing
>> the file, it would look differently that it does in the editor...
>
> (Skip the next chapter to read something useful...)
>
> And I again opposite to your opinion. 

And I agree with JWZ: 

-- 
Juha Autero
http://www.iki.fi/jautero/
Eschew obscurity!


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

.pyo files.

[Luca - De Whiskey's - De Vitis]

I'm wandering why so many (if not all) python modules compile the py files
twice: first simply, then with the -O flag.
Reading the python documentation it seems that this does not improve the
perfomance so much. OTOH, it increase the disk usage a lot. More over, if you
compile a module with -O python will ignore the .pyc files.

Thanks for your time,
-- 
Luca - De Whiskey's - De Vitis  | Elegant or ugly code as well
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have
Luca, a wannabe ``Good guy''.   | something in common: they
local LANG="[EMAIL PROTECTED]" | don't depend on the 
language.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Packaging, supporting both 2.1 and 2.2

[Donovan Baarda]

On Wed, May 22, 2002 at 04:50:02PM -, Moshe Zadka wrote:
> On Wed, 22 May 2002, Bastian Kleineidam <[EMAIL PROTECTED]> wrote:
> 
> > Ok, thats a problem. There is no way out for this; you'd have to
> > have two binaries.
> 
> Yes, I know I'll have to have two binaries.

if I understand it, foo is not really a 'binary' but an 'executable
script'... (which means it can be Python version independant).

This situation is identical to the existing idle package. It's worth looking
at how it handles it.

You have several options if you want python2.1 and python2.2 supported;


1) have foo.py support python2.1, python2.2, provide foo-python2.1 using
python2.1 and foo-python2.2 using python2.2.

make python2.1-foo (Depends: python2.1), python2.2-foo (Depends: python2.2),
foo-python2.1 (Depends: python2.1, python2.1-foo) with
/usr/bin/foo-python2.1 using '#!/usr/bin/python2.1', foo-python2.2 (Depends:
python2.2, python2.2-foo) with /usr/bin/foo-python2.2 using
'#!/usr/bin/python2.2'.


1a) as 1), but also provide foo symlink for python (default).

as 1), but also make foo (Depends: python (>=2.1), python (<<2.2),
foo-python2.1) with symlink /usr/bin/foo to /usr/bin/foo-python2.2


1b) as 1), but also provide foo symlink using Debian alternatives.

as 1) but make packages foo-python2.1 and foo-python2.2 use Debian
alternatives for /usr/bin/foo.


The 1) options all force developers using foo.py to choose between 2.1 and
2.2. They cannot just depend on the default python, forcing them into
cascading package updates when they change python versions. The varients
simply provide different ways of making the foo script more accessable. The
following alternatives allow developers to depend on the default python and
minimise their package dates.


2) have foo.py support python2.1, python2.2, python (default), provide foo
using python (default).

make python2.1-foo (Depends: python2.1), python2.2-foo (Depends: python2.2),
python-foo (Depends: python (>=1.1),python (<<2.2), python2.1-foo) wrapper,
foo (Depends: python, python-foo) with /usr/bin/foo using
'#!/usr/bin/python'.

This follows the policy to the letter. It allows developers to use foo.py
with any of the three python versions. The python (default) is an alias for
2.1 in woody, but when the default changes to 2.2, packages that depend on
the default will not need to be updated to use it. When the default becomes
2.2, you just need to release a new python-foo (Depends: python (>=2.2),
python (<<2.3), python2.2-foo) wrapper package, and foo will automaticly be
using python2.2.


2a) have foo.py support python2.1, python2.2, python (default), incidentaly
provide foo using python (default).

make python2.1-foo (Depends: python2.1), python2.2-foo (Depends: python2.2),
python-foo (Depends: python (>=1.1),python (<<2.2), python2.1-foo) with
/usr/bin/foo using '#!/usr/bin/python'.

This deviates from the policy a tiny bit in that python-foo is more than
just a wrapper package because it includes the /usr/bin/foo script. However,
it does eliminate one extra foo package and otherwise provides all the
benefits above.


3) use python-central to have foo.py support python2.1, python2.2, python
(default), provide foo using python (default)

make python-foo (Depends: python2.1 | python2.2, python-central), foo
(Depends: python, python-foo) with /usr/bin/foo using '#!/usr/bin/python.


3a) use python-central to have foo.py support python2.1, python2.2, python
(default), incidentaly provide foo using python (default)

make python-foo (Depends: python, python2.1 | python2.2, python-central)
with /usr/bin/foo using '#!/usr/bin/python'.


python-central is not part of the policy yet, and probably will not be in
woody. Using python-central would require you to put modules in
/usr/lib/python/site-packages and call 'register-python-package
(configure|remove) python-foo' in the postinst/prerm scripts.

how you provide python-foo and foo is fairly disjoint, and you can probably
mix-n-match the foo and python-foo packaging options (ie option 3
python-foo, option 1b foo), provided you carefuly think out the dependancy
implications.

-- 
--
ABO: finger [EMAIL PROTECTED] for more info, including pgp key
--


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Packaging, supporting both 2.1 and 2.2

[Donovan Baarda]

On Thu, May 23, 2002 at 10:10:51AM +1000, Donovan Baarda wrote:
[...]
> 1a) as 1), but also provide foo symlink for python (default).
> 
> as 1), but also make foo (Depends: python (>=2.1), python (<<2.2),
> foo-python2.1) with symlink /usr/bin/foo to /usr/bin/foo-python2.2

Ack! typo... should be /usr/bin/foo-python2.1

> The 1) options all force developers using foo.py to choose between 2.1 and
> 2.2. They cannot just depend on the default python, forcing them into
> cascading package updates when they change python versions. The varients
> simply provide different ways of making the foo script more accessable. The
> following alternatives allow developers to depend on the default python and
> minimise their package dates.

...updates.

-- 
--
ABO: finger [EMAIL PROTECTED] for more info, including pgp key
--


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Packaging, supporting both 2.1 and 2.2

[Moshe Zadka]

On Thu, 23 May 2002, [EMAIL PROTECTED] (Donovan Baarda) wrote:

> if I understand it, foo is not really a 'binary' but an 'executable
> script'... (which means it can be Python version independant).

Yep.

> This situation is identical to the existing idle package. It's worth looking
> at how it handles it.

I'll take a look, thanks.

> 1) have foo.py support python2.1, python2.2, provide foo-python2.1 using
> python2.1 and foo-python2.2 using python2.2.
> 
> make python2.1-foo (Depends: python2.1), python2.2-foo (Depends: python2.2),
> foo-python2.1 (Depends: python2.1, python2.1-foo) with
> /usr/bin/foo-python2.1 using '#!/usr/bin/python2.1', foo-python2.2 (Depends:
> python2.2, python2.2-foo) with /usr/bin/foo-python2.2 using
> '#!/usr/bin/python2.2'.

except there is no way to install something at "/usr/bin/foo". Users should
not *have* to care about python versions.

> 1a) as 1), but also provide foo symlink for python (default).

this makes senseI can just put the symlink in python2.1-foo-bin and
move the symlinks when a python default change.

> as 1), but also make foo (Depends: python (>=2.1), python (<<2.2),
> foo-python2.1) with symlink /usr/bin/foo to /usr/bin/foo-python2.2

so that if I go MIA I'm keeping python back? ugh ;-)

> 1b) as 1), but also provide foo symlink using Debian alternatives.

Like I said, this is very high maintainence -- in real life, scripts
are added to upstream package frequently, and I don't want to echo
this in my postinst/prerm

> The 1) options all force developers using foo.py to choose between 2.1 and
> 2.2. 

I don't think I mind that. developers can either support both or support
just one, and change which one they're supporting when they want to.

> 2) have foo.py support python2.1, python2.2, python (default), provide foo
> using python (default).
> 
> make python2.1-foo (Depends: python2.1), python2.2-foo (Depends: python2.2),
> python-foo (Depends: python (>=1.1),python (<<2.2), python2.1-foo) wrapper,
> foo (Depends: python, python-foo) with /usr/bin/foo using
> '#!/usr/bin/python'.

Except that again, my package is holding up a default python change.

> 3) use python-central to have foo.py support python2.1, python2.2, python
> (default), provide foo using python (default)

AIUI python-central is still not there yet, correct? A lot of people are
already needing both 2.1 and 2.2 support, so I'll make do and when p-c
comes along, I'll see if I want to switch to it.

> python-central is not part of the policy yet, and probably will not be in
> woody. 

woody is irrelevant -- I wouldn't make such changes in woody.

I'm thinking of doing 1a above -- people who don't give a damn won't care
about the versions and people who do can run "foo2.2" for all I care.

In short: installing python2.1-foo will have foo.py, /usr/bin/foo2.1 and
a foo->foo2.1 symlink. installing python2.2-foo will have foo.py, 
/usr/bin/foo2.2 and no symlink. I'll create the symlink in d/r based on
the default python version on the build system, so rebuilding after python2.2
is default will cause the symlink to move from python2.1-foo to
python2.2-foo. it will also cause the dummy package python-foo to move from
depending on python2.1-foo to depending on python2.2-foo.

Unless anyone sees any problem with it, here is what I will use to find out
the default python on the build system:
/usr/bin/python -c 'import sys;v=sys.hexversion;print "%s.%s" % ((v>>24)&0xff, 
(v>>16)&0xff)'


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]