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

Re: python-central vs python-support



On Fri, 2006-06-09 at 08:32 +0200, Raphael Hertzog wrote:
> On Mon, 05 Jun 2006, Raphael Hertzog wrote:
> > On Sun, 04 Jun 2006, Joe Wreschnig wrote:
> > > policy is. So here's *my* attempt at summarizing the BoF, based on your
> > > first mail and responses, and independent of the tools used:
> > > 
> > > 1) Public modules and extensions should support all available Python
> > > versions, using a single binary package.
> > > 
> > > 2) A new control field, XC-Python-Version will be used to determine what
> > > versions of Python a module supports.
> > > 
> > > 3) The tight upper bound on module dependencies will be removed,
> > > provided the module actually works on future versions of Python. The
> > > upper bound on extension dependencies will not, because then they
> > > wouldn't work.
> > > 
> > > 4) python2.x-* virtual packages are to be used only when necessary, but
> > > packages can provide them regardless.
> > > 
> > > 5) Private modules and applications should use some way to support more
> > > than one Python version, if possible.
> > > 
> > > Is this accurate? 1), 3), and 4) contridict your original email, but
> > > match what you told me this time.
> > 
> > Yes, this is a good summary IMO, however I don't remember if we discussed
> > point 5.
> 
> Joe, could you integrate all this in the real document of the python policy?
> Any other volunteer for that task?

I will try to write something up Monday; I need to set aside some time
to watch the BoF properly, and want to reread the pycentral/support code
before I try to formalize the policy. If someone else wants to preempt
me feel free.

It also depends a little on how the implementation details play out, I
guess. I can write the policy strictly independently of the tools, but
the current policy has a lot of example code, and I'd like to keep that
too.
-- 
Joe Wreschnig <piman@sacredchao.net>

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: