> I think this is fine, however we do need to be more explicit about cases where > a package is either split into bilingual libraries + executable, or just an > application with ancillary libraries (some might say "private" library).
python-foo packages have to provide public libraries, you can ship additional private libraries or scripts in the same package but I think it's cleaner to separate them into new binary package (especially if this application/private library requires additional dependencies). If you want to ship a private library that works with 3.X only then it simply is not acceptable due to additional python3 dependency (you cannot force anyone to install python3 when you apt-get install python-foo) > There are lots of examples where the latter exists in python-foo binary > packages. virtualenv was a prime example and its Python 3 executable has now > been moved to `virtualenv` (no prefix). If we cannot have a Python 3 > application live in a python-foo binary package, then we need to be explicit > about this in Python policy, and the application style guide. policy mentions that Python 2.X and Python 3.X are separate languages for us and that's why we have python-foo and python3-foo packages. I don't want APT to install python3 when I install python-foo and I don't want APT to install python when I install python3-foo. If you want one package to provide Python 2.X and Python 3.X code - it's fine, just don't use "python-" or "python3-" prefix in package name and don't provide public libraries. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
