Andreas Enge <[email protected]> skribis: > Am Mittwoch, 28. August 2013 schrieb Ludovic Courtès: >> > +(define-public python3 >> >> Nice that it works without any modifications. Please push. (I think >> Andreas wanted to discuss the naming convention for Python packages, but >> I think adding Python 3 doesn’t cause any problems.) > > Only a little ;-) > > I would rename > (define-public python > to > (define-public python-2 > > and add > (define-public python > for python version 3 (compare libjpeg for version 9 and libjpeg-8).
What about having 3 variables: python-3, python-2, and python; ‘python’ would point to whichever is the default. For GCC and Guile we don’t even have the version-less variable name. Instead ‘gnu-build-system’ explicitly refers to the one we want. Anyway, I don’t think this should block this patch. > Then all packages relying on python will be recompiled with the newest > version. If this poses problems, we could modify the input to python-2. > > Rationale: We would like to package the newest versions and give their > variables the default names. If for compatibility problems, we need an > older version, the corresponding variable should get a suffix. (While the > NAME field of a package should be the default name in all cases.) Sounds like the right approach for a start. However, some packages will work with both versions, while others will be 2-only or 3-only. We’ll most likely build both variants for those that work with both 2 and 3, for instance because there’s both a 2-only and a 3-only package that depends on them. Thus, eventually, there may be a need for a procedure that rewrites a package to explicitly depend on a given package version (similar to ‘rewritten-inputs’ in build-system/gnu.scm). Ludo’.
