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.
