On Wed, 19 Jan 2011 00:55:40 +0100
Michael scherer <m...@zarb.org> wrote:
> 
> > The solution of generating bytecode at install time looks fine. I am
> > not an RPM specialist though, but if you have non-RPM specific questions
> > feel free to ask them, I'd be glad to answer.
> 
> Well, that's not satisfying from a rpm pov, unfortunately. 

Can you explain why it isn't? I'm sure other packages generate stuff at
install-time, right? Also, the list of files is well-known (it's
everything named "*.py" that goes somewhere inside /usr/lib/pythonXXX/).

> > What is the issue with "handling 2to3"? It's a developer tool and
> > certainly shouldn't be invoked at install time if that's what you are
> > asking. Generally, I don't think you (as a packager) have to invoke
> > 2to3 manually at all. If 2to3 is part of the packaged software's build
> > process, then their setup.py will probably invoke it automatically with
> > the right options.
> 
> I as more speaking of the transition from pyton 2 to python 3. I think the 
> easiest
> on a policy point of view is to handle this like 2 separate languages, but 
> that mean twice the work.
> And so we should at least try to  do better ( not sure that we can, of course 
> ).

Handling them as two separate languages looks indeed like the right
thing to do, IMO. In any case, as I said, you shouldn't be the one
wondering about 2to3. Upstream developers do, if that's the conversion
method they chose for their project.

I'm not sure about "twice the work": you don't need to track twice the
software releases (except for the interpreter itself), or twice the
upstream patches, etc.

Regards

Antoine.


Reply via email to