Up to 1.5.6, pyparsing had two .py files in the package -- one for py2 and one for py3. Then upstream split the package. Now, pyparsing-1.5.7 supports only Python 2 and pyparsing-2.0.0 only Python 3. I'm not sure how compatible the versions are, the diff is a bit long. What should we do now? a) create an ugly mixed ebuild like pyparsing-1.5.7.2.0.0 which fetches both sources and installs one version or the other, b) slot pyparsing, into 1.5.7:1 and 2.0.0:2. Create virtual/pyparsing which will grab the correct ebuild depending on Python implementations requested.
Solution (b) seems better so far, but you haven't listed any advantages/disadvantages of both approaches.
Well, in short words: a) Advantages: 1) we have only a single package for it, 2) deps don't have to change. Disadv.: 1) hacky ebuild, hacky version numbers, 2) i'm not sure if upstream is going to develop 1.* anymore, 3) i don't think we're going to make sure that the codebases don't diverge. 2) could mean that we're going to have 1.5.7.2.0.0, then 1.5.7.2.0.1, and so on. And 3) would mean that at some point we may be actually installing two different versions of 'pyparsing' and pretending it's just one module which supports both py2 & py3. b) Advantages: 1) clean, sane and so on, 2) safe for upstream stopping to develop 2.x variant. Disadvantages: 1) more packages, 2) need to update the deps in the tree. In case upstream stops supporting 1.* and 2.* diverges too much, we can just add a new virtual/ version which does not support python-2 at all.
Thanks, that's useful. Put like that, creating a virtual seems a bit heavy-weight; is it possible to come up with a way to get the deps right without that? Perhaps the depending package could grow yet another variable? PY_VER_DEP="py2? dep:1 py3? dep:2"
(In reply to comment #3) > Thanks, that's useful. Put like that, creating a virtual seems a bit > heavy-weight; is it possible to come up with a way to get the deps right > without that? Perhaps the depending package could grow yet another variable? > > PY_VER_DEP="py2? dep:1 py3? dep:2" To be honest, I don't like this idea. It drops the responsibility for checking the pyparsing deps to the ebuilds, while being practically equivalent to the virtual.
Silly idea: hard-coded list in the eclass?
(In reply to comment #5) > Silly idea: hard-coded list in the eclass? That's just reinventing the concept of virtuals in the eclass IMO.
Maybe, but it does get rid of the disadvantages you mention for (b): (1), we don't have more packages, and (2) we don't need to update the deps in the tree.
(In reply to comment #7) > Maybe, but it does get rid of the disadvantages you mention for (b): (1), we > don't have more packages, and (2) we don't need to update the deps in the > tree. But we have more code in the eclass which is a bit package-centric. That starts to raise questions, and all the metadata in the tree needs to be updated.
(In reply to comment #7) > Maybe, but it does get rid of the disadvantages you mention for (b): (1), we > don't have more packages, and (2) we don't need to update the deps in the > tree. I'd forget: how can we do it? I don't think it will be really helpful to say 'for pyparsing dep, you need to use $(python_get_pyparsing_dep) instead of the package dep'...
> I don't think it will be really helpful to say 'for pyparsing dep, you need > to use $(python_get_pyparsing_dep) instead of the package dep'... How I would code it in python: VERDEP = {"dev-python/pyparsing": [['=', '1.5.7'], ['>=', 2.0.0']]} for dep in pkg_deps: if dep.pkg in VERDEP: pkg_deps.remove(dep) new = VERDEP[dep.pkg] pkg_deps.append(new[0] + dep.pkg + '-' + new[1])
(In reply to comment #10) > > I don't think it will be really helpful to say 'for pyparsing dep, you need > > to use $(python_get_pyparsing_dep) instead of the package dep'... > > How I would code it in python: > > VERDEP = {"dev-python/pyparsing": [['=', '1.5.7'], ['>=', 2.0.0']]} > for dep in pkg_deps: > if dep.pkg in VERDEP: > pkg_deps.remove(dep) > new = VERDEP[dep.pkg] > pkg_deps.append(new[0] + dep.pkg + '-' + new[1]) I understand your intent but eclass can't access or modify package dependencies. It would need to be something explicitly requested by the package. Therefore, it's only the question of whether user puts well-known virtual/pyparsing or something like $(python_get_pyparsing_dep). With the virtual being a common way of handling that kind of deps, and eclass being a custom solution which is a bit too centric IMO, esp. with the design of the eclasses.
Alright, let's just go with the virtual, then. Mike, agree?
Yeah, virtual sounds good to me. I don't like the idea of combining two packages that have been separated upstream.
Another possibility is to have pyparsing-2 (in a new slot), which nominally supports all versions of Python, but does not install any files for Python 2, and depends on: 2.5? ( =dev-python/pyparsing-1*[2.5] ) 2.6? ( =dev-python/pyparsing-1*[2.6] ) 2.7? ( =dev-python/pyparsing-1*[2.7] ) ... Then reverse dependencies would not need to be migrated to depend on a virtual.
Ooh, I must admit I rather like that idea.
(In reply to comment #14) > Another possibility is to have pyparsing-2 (in a new slot), which nominally > supports all versions of Python, but does not install any files for Python > 2, and depends on: > 2.5? ( =dev-python/pyparsing-1*[2.5] ) > 2.6? ( =dev-python/pyparsing-1*[2.6] ) > 2.7? ( =dev-python/pyparsing-1*[2.7] ) > ... > > Then reverse dependencies would not need to be migrated to depend on a > virtual. Good time to wake up. I've just committed the virtual... But it's basically the same idea as the both-in-one ebuild, just that you put it out to two ebuilds...
This idea does not have any disadvantages mentioned for solution A from comment #0. You should wait more than half day before implementing controversial changes.
(In reply to comment #17) > This idea does not have any disadvantages mentioned for solution A from > comment #0. > > You should wait more than half day before implementing controversial changes. What is 'controversial' here?
The virtual and the ebuild are now committed.
