[Mageia-dev] Python Packaging Policy
misc at zarb.org
Wed Jan 19 08:25:23 CET 2011
On Wed, Jan 19, 2011 at 02:07:18AM +0100, Antoine Pitrou wrote:
> On Wed, 19 Jan 2011 00:55:40 +0100
> Michael scherer <misc at 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/).
Because that would 1) requires a patch to rpm that we do not have or
2) patch all python packages to had %ghost on all *.pyc, and do a compilation of
*pyc ( the 2nd part is easy, the first one is slightly harder to automate )
3) do not care about file tracking, but that's unclean.
Do not get me wrong, I think that's the way forward, but that's not applicable
in a few days.
And I cannot think of a rpm generating stuff at install time that do not requires
specific intervention in the spec. Usually, we have packages that register themself
in a dynamic list ( man, info, .desktop ), or that trigger symlink
( updates-alternatives ) , and those symlink are not tracked by rpm, and that's a
suboptimal solution ( ie, you cannot do a research by file name, etc )
> > > 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.
Well, I was not clear, when i said "2to3", i didn't mean't the tools at all.
Rather the fact we have to handle the migration, my sentences was poorly worded.
> 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.
Well, if we handle this like 2 separates languages, that mean 2 separates rpms for
each modules. Or we should be clever when generating 1 rpm to have the modules
for both python 3 and python 2 generated ( Except when the developper did choose
to have separate tarball or code base )
Having one rpm that produces 2 modules also mean that we will rebuild all modules
for python3 and all for python2, and I know that for example Buchan will not like
the extranous trafic it would generate.
So IMHO, there is various things to discuss.
More information about the Mageia-dev