Re: python packaging infrastructure
Josselin Mouette writes:
> > correct, but making it easier for extensions and applications using
> > private modules as well. when will python-support be able to support
> > these?
>
> Python-support already handles private modules. As for extensions, I
> don't think we should change the current packaging practise. Packaging
> them is already complicated enough as it is.
yes, a reason to simplify this. AFAIK the support for private modules
is based on your stateful approach, which will go away?
> > > There are not many libraries that are present in Debian with several
> > > versions at the same time, and I don't think they are good examples of
> > > sane practise we should follow.
> >
> > I still see python2.5 as the default version for etch as a possible
> > goal, with some applications not yet ready for this one using an older
> > version. Any packaging infrastructure which will allow testing this
> > outside the archive first will help. And this includes again
> > extensions and applications using private modules.
>
> I am not arguing against keeping several versions of the interpreter
> available. Developers need to test their applications with different
> versions. Now, if we have:
> - python-only modules and private modules handled by python-support;
> - several python2.X versions available in the archive;
> - for extensions, several python2.X-foo and a default python-foo as we
> do today;
> with all of this, testing each application against a new python version
> outside the archive becomes possible. Not trivial, but possible.
This is the right direction, and adding support for extensions makes
this complete. Does your proposal allow rebuilding these packages
without actually changing anything (except the changelog).
I have a strong opinion to support a solution which covers all python
packages. If python-support cannot handle it and there's another
option, I prefer that one including the meta information in the
control file.
Matthias
Reply to: