1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
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>
|
