diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20110119/002233.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20110119/002233.html | 118 |
1 files changed, 118 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20110119/002233.html b/zarb-ml/mageia-dev/20110119/002233.html new file mode 100644 index 000000000..1e6e35491 --- /dev/null +++ b/zarb-ml/mageia-dev/20110119/002233.html @@ -0,0 +1,118 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Python Packaging Policy + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Python%20Packaging%20Policy&In-Reply-To=%3C20110119072523.GA2739%40sisay.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="002231.html"> + <LINK REL="Next" HREF="002238.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Python Packaging Policy</H1> + <B>Michael scherer</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Python%20Packaging%20Policy&In-Reply-To=%3C20110119072523.GA2739%40sisay.ephaone.org%3E" + TITLE="[Mageia-dev] Python Packaging Policy">misc at zarb.org + </A><BR> + <I>Wed Jan 19 08:25:23 CET 2011</I> + <P><UL> + <LI>Previous message: <A HREF="002231.html">[Mageia-dev] Python Packaging Policy +</A></li> + <LI>Next message: <A HREF="002238.html">[Mageia-dev] Python Packaging Policy +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2233">[ date ]</a> + <a href="thread.html#2233">[ thread ]</a> + <a href="subject.html#2233">[ subject ]</a> + <a href="author.html#2233">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On Wed, Jan 19, 2011 at 02:07:18AM +0100, Antoine Pitrou wrote: +><i> On Wed, 19 Jan 2011 00:55:40 +0100 +</I>><i> Michael scherer <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">misc at zarb.org</A>> wrote: +</I>><i> > +</I>><i> > > The solution of generating bytecode at install time looks fine. I am +</I>><i> > > not an RPM specialist though, but if you have non-RPM specific questions +</I>><i> > > feel free to ask them, I'd be glad to answer. +</I>><i> > +</I>><i> > Well, that's not satisfying from a rpm pov, unfortunately. +</I>><i> +</I>><i> Can you explain why it isn't? I'm sure other packages generate stuff at +</I>><i> install-time, right? Also, the list of files is well-known (it's +</I>><i> everything named "*.py" that goes somewhere inside /usr/lib/pythonXXX/). +</I> +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 ) + +><i> > > What is the issue with "handling 2to3"? It's a developer tool and +</I>><i> > > certainly shouldn't be invoked at install time if that's what you are +</I>><i> > > asking. Generally, I don't think you (as a packager) have to invoke +</I>><i> > > 2to3 manually at all. If 2to3 is part of the packaged software's build +</I>><i> > > process, then their setup.py will probably invoke it automatically with +</I>><i> > > the right options. +</I>><i> > +</I>><i> > I as more speaking of the transition from pyton 2 to python 3. I think the easiest +</I>><i> > on a policy point of view is to handle this like 2 separate languages, but that mean twice the work. +</I>><i> > And so we should at least try to do better ( not sure that we can, of course ). +</I>><i> +</I>><i> Handling them as two separate languages looks indeed like the right +</I>><i> thing to do, IMO. In any case, as I said, you shouldn't be the one +</I>><i> wondering about 2to3. Upstream developers do, if that's the conversion +</I>><i> method they chose for their project. +</I> +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> I'm not sure about "twice the work": you don't need to track twice the +</I>><i> software releases (except for the interpreter itself), or twice the +</I>><i> upstream patches, etc. +</I> +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. +-- +Michael Scherer +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="002231.html">[Mageia-dev] Python Packaging Policy +</A></li> + <LI>Next message: <A HREF="002238.html">[Mageia-dev] Python Packaging Policy +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2233">[ date ]</a> + <a href="thread.html#2233">[ thread ]</a> + <a href="subject.html#2233">[ subject ]</a> + <a href="author.html#2233">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |