python-kid

Pavel Å imerda · External Since: Feb 01, 2006 Posts: 5

Hi people....
I debian/testing there's a deb package called just 'kid'. It's a very nice
templating system for python.

Debian's package 'kid' is for python2.3... so I'd maybe prefer calling it
python2.3-kid.

And there's no python2.4 version of this package...
Although it's easy to install it using python2.4 setup.py install... it
doesn't install 2.4's scripts properly.

Pavel

--
To UNSUBSCRIBE, email to debian-python-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

Josselin Mouette · External Since: Nov 09, 2004 Posts: 1252

Le jeudi 09 février 2006 à 22:57 +0100, Pavel ¦imerda a écrit :
> At first look I thought python packages in debian are called
> python2.3-packagename and python2.4-packagename. And that there's a
> metapackage python-packagename that requires the 2.3 version installed.
>
> Now I see this is not so with all packages.... and it is hard to see which
> packages are present in python2.3 and missing in python2.4.

Of course this is not the case for all packages. We don't need 4 binary
packages for each python-foobar module.

For a module that has few or zero reverse dependencies, there should be
one single package, named python-foo, containing the module for the
default python version. Anything else is just cluttering the archive.
--
.''`. Josselin Mouette /\./\
: :' : josselin.mouette DeleteThis @ens-lyon.org
`. `' joss DeleteThis @debian.org
`- Debian GNU/Linux -- The power of freedom

Pavel ¦imerda · External Since: Feb 10, 2006 Posts: 1

On 2006-02-10 09:05, Josselin Mouette wrote:
> Le jeudi 09 février 2006 à 22:57 +0100, Pavel ¦imerda a écrit :
> > At first look I thought python packages in debian are called
> > python2.3-packagename and python2.4-packagename. And that there's a
> > metapackage python-packagename that requires the 2.3 version installed.
> >
> > Now I see this is not so with all packages.... and it is hard to see
> > which packages are present in python2.3 and missing in python2.4.
>
> Of course this is not the case for all packages. We don't need 4 binary
> packages for each python-foobar module.
>
> For a module that has few or zero reverse dependencies, there should be
> one single package, named python-foo, containing the module for the
> default python version. Anything else is just cluttering the archive.

You think it's better to force users to a specific version... I thought MOST
of the packages were in two binary versions (2.3 and 2.4) with one dummy
package dependant on the default. It seems you don't like peple who'd like to
make their own packages do you?

I don't mean it bad... I already switched to setup.py installation instead of
apt so I can use python2.4 now. I'm just trying to make things better for
other users.

Pavel

Pavel Å imerda · External Since: Feb 01, 2006 Posts: 5

> That depends ... if you need some 3rd party package/module that debian
> built only for 2.3 then yes, but if all the package/modules that you
> need have python2.4 builds in debian then you can use 2.4.
this is the case with wxWidgets and kid

> See the Python Policy for the various circumstances for each
> arrangement.
Hmm, I've just read it. It really allows python-something to be package
'something' for the default version of python.

Still wouldn't be better to name the packages according to python version from
the start? For easier and more reliable dependency management?

And... I would expect I was not the only user to list all python 2.3/2.4
packages to see what apt repository offers (and at the same time, what you
can do with python) - examining python2.3-* packages one by one.

> | would it be so difficult to rename the packages according to this scheme?
>
> For some it isn't, for some it is.
For some it is difficult? Why?
Dependencies are maintained, apt-get install still works without changing
package name... but it gives the programmers a bit more freedom.

>
> [...]
>
> | Then there's also package python-wxgtk2.6:
> | * as it's actually python2.3 version, I would rename it
> | python2.3-wxgtk2.6 * metapackage python-wxgtk2.6 depending on
> | python2.3-wxgtk2.6
> | * what about python-wxgtk (?)
> | (* again, we would be prepared for python2.4-wxgtk2.6)
>
> I haven't built wx, but I can imagine that it would not be trivial.
> The maintainer chose to only build one variation, and so it is only
> for the default version (python 2.3) and doesn't specify that version
> in the package name. If you were to simultaneously build a python 2.4
> version, then that naming would be appropriate.
Hmm this looks like saying... I'll name it python-* because we're not going to
make this package for 2.4.
> At this point we really just need to move the default to 2.4. 2.4 has
> been available for a rather long time now.
Yes, I agree, couldn't this be the first step? To have all packages working as
python2.4-* and finally just modify python2.3 and python2.4... and then
switch at once, changing only the dependencies.

> PS I am aware of several factors (including C++ and other
> transitions) that resulted in not starting a python transition
> sooner. Regardless, 2.4 isn't "new" anymore and ought to be the
> default. I look forward to seeing this happen Smile

.
Ok

--
To UNSUBSCRIBE, email to debian-python-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

Pavel Å imerda · External Since: Feb 01, 2006 Posts: 5

On 2006-02-10 18:12, Josselin Mouette wrote:
> Le vendredi 10 fÃ©vrier 2006 Ã 16:46 +0100, Pavel Å imerda a Ã©crit :
> > > For a module that has few or zero reverse dependencies, there should be
> > > one single package, named python-foo, containing the module for the
> > > default python version. Anything else is just cluttering the archive.
> >
> > You think it's better to force users to a specific version... I thought
> > MOST of the packages were in two binary versions (2.3 and 2.4) with one
> > dummy package dependant on the default. It seems you don't like peple
> > who'd like to make their own packages do you?
>
> I don't like people who like to provide several packages just for the
> pleasure of providing several packages.
Not an anwer at all. I mean someone would like to package his program or tool
and make it dependant on kid0.8 templates and python2.4.

So he sets the dependency: kid (>= 0. Cool

and python2.4.... currently, kid is
installed in python 2.3 and the dependency just fails. I hate broken
dependencies Wink

as much as any user does

When you need python2.4 (not only 2.3) with cherrypy2.1 (not only 2.0), all
works great.
You set it dependent on python2.4-cherrypy2.1 which depends on python2.4, and
is installed in its structure.

In these cases I don't even need python-* type of packages... because I know
which versions I support in my programs.

I quite like meta-packages, that make dependencies work better. I allways
thought this is a strong point of APT.
>
> > I don't mean it bad... I already switched to setup.py installation
> > instead of apt so I can use python2.4 now. I'm just trying to make things
> > better for other users.
>
> You should think of comparing the value added by providing several
> packages and the cost of cluttering the archive and confusing users. Ask
> yourself whether this is worth the complication.
I am thinking about it... as I was one of the confused users - confused that
python-* is sometimes a metapackage and sometimes a real package. (Not from
the total number of packages related to python.)

And because i was looking at python package called kid... expected python-kid
but that was just 'kid'... searched for 2.4 version but there is none....

And also confused by the fact that python2.3 and python2.4 families are not at
all complete as I expected.

Pavel Å imerda · External Since: Feb 01, 2006 Posts: 5

> Take, for example, sharpmusique. I want to be able to browse the
> iTMS. Since I don't develop with C# or Mono/.NET I don't know
> anything about the different versions of each and I really don't care.
> I just want the application to work. The package depends on a version
> of mono that works, and I'm a happy user.

I was talking about libraries... sorry for not being clear enough.
And... I don't know about non-library packages called python*-package (maybe
there are some).
I thought application packages are named as any non-python program.

> Likewise you don't ask for different packages of kmail (or python),
> one built with each version of gcc. If it works, you don't care Smile

.

See above.

> However, if the software is a library and the user of the software is
> a developer, then the version of python may matter and you may have
> reasonable use cases for having a 2.3 and a 2.4 version. I would be
> highly skeptical if you also claimed that you need a 2.2, 2.1 and/or
> 2.0 version.

What I want is... the latest version, and maybe those versions that are needed
to run some applications.

I thing for debian it's 2.4 and 2.3, so you don't have to [be sceptical].

> A lot of libraries are provided this way. I don't think any
> applications are. Some libraries aren't, because the maintainer
> decided the return on investment for supporting a non-default version
> of python is too low for the cost involved.

The same misunderstanding... library packages, of course

> Ideally there would be exactly one version of python, and exactly one
> package for each of the extension modules and applications using
> python. This is not really practical because python improves and new
> versions become available. Developers (users of debian) will need
> multiple versions of python to ensure that the products they develop
> are compatible with the range of python versions they expect users of
> their product will use. The compromise is that debian provides a
> python package marked as the 'default' version. This is the 'exactly
> one' version in the ideal scenario. In practice, other non-default
> versions of python are provided as well. Individually the maintainers
> of each package that uses python can choose to support only the
> default python, or support the default and any other optional versions
> they choose to support. An exception is if the default python is to
> obsolete and their package only works with a newer version.

That's what I would expect... but a python user (I mean programming language
user / developer) must code for python 2.3 now, if he uses libraries such as
wxWidgets or kid. Even if those libraries run perfectly on python 2.4.

Python improves and developers want to code for the current version, not the
old one, in my opinion.

And, btw... the scheme you are describing would work ONLY if all libraries
were named python<version>-package.... and default version in a metapackage.

Maintainer cannot choose the dependency (working with several versions of
python installed) for an application using wxWidgets... because there is no
python 2.3 version and no python2.4 version.... He has to use the default
version allways.

So if you make (or package) wx applications there is only one version of
python and all python<version>-library packages are of no use to you.

> As I mentioned before, the real problem is that etch's default python
> is still 2.3, which is now quite obsolete. If the transition to
> making 2.4 the default were complete you would have nothing to
> complain about Smile

.

That's right....

But I'd like at least one way working... alright, there is one way working....
setup.py Wink

Pavel

--
To UNSUBSCRIBE, email to debian-python-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

Matthias Klose · External Since: Nov 10, 2004 Posts: 1107

Donovan Baarda writes:
> On Thu, 2006-02-09 at 17:09 -0500, Derrick Hudson wrote:
> > On Thu, Feb 09, 2006 at 10:57:50PM +0100, Pavel Å imerda wrote:
> [...]
> > At this point we really just need to move the default to 2.4. 2.4 has
> > been available for a rather long time now.
> >
> > -D
> >
> > PS I am aware of several factors (including C++ and other
> > transitions) that resulted in not starting a python transition
> > sooner. Regardless, 2.4 isn't "new" anymore and ought to be the
> > default. I look forward to seeing this happen Smile

.

yes. As pointed out, there have been problems with both
python-central/python-support, regarding the handling of
dependencies. I'm going to upload a new python package which handles
recompilation of packages with "private" modules (outside the default
sys.path). Then we can start the transition. Still evaluating an
extension of python-support, if we can just drop the dependency of
pure library packages to the interpreter at all.

> Note that Ubuntu transitioned to python2.4 as the default some time ago
> (and they have almost complete support for python's all the way back to
> python2.1) ... given the appearance of python-minimal I think Debian is
> leveraging off their work and will hopefully get there soon.
>
> In the mean time, another alternative is to point your apt/sources.list
> at an Ubuntu archive and see if you can upgrade python from there...

ugh, I would not try that ... you cannot differentiate between python
and non-python things ...

Matthias