Re: multiple modules in one source
On 12 December 2014 at 09:48, Ben Finney ben+deb...@benfinney.id.au wrote: Just about any non-trivial Python package (and some trivial ones) in Debian will have many distinct modules. Possibly I am getting my terminology confused. You're familiar with ‘python-django’, as just one example. Including django.contrib, django.core, etc. In the case of Django, everything is under the django module. Do you mean “multiple distinct Python packages”? Not sure calling it multiple distinct Python packages is correct, currently there is only one setup.py, and hence only one egg file produced. e.g. package contains setup.py module1/__init__.py module1/something.py module2/__init__.py module2/somethingelse.py debian/rules debian/control etc. As for Python source distributions: the ‘distutils’ library allows nominating multiple top-level packages to build, and those can be shipped in a single ‘sdist’ and appear in a single Debian source package. Once built to a ‘bdist’, the resulting Python packages can be built to distinct Debian binary packages. Often that makes sense. Is this possible with dh --buildsystem=pybuild? I guess another possibility would be to have multiple python packages, but commit everything in one git tree, e.g.: package1/setup.py package1/module1/__init__.py package1/module1/something.py package2/setup.py package2/module1/__init__.py package2/module1/something.py debian/rules debian/control Wonder how to do this with dh and pybuild? Would the following be sane? %: dh $@ --with python2,python3 --buildsystem=pybuild --dir=package1 dh $@ --with python2,python3 --buildsystem=pybuild --dir=package2 (unfortunately the --dir parameter doesn't appear have any effect; lets pretend I worked out the correct command line option to do this) An example of a single source repository which contains multiple distinct Python packages is Docutils. The ‘python-docutils’ Debian source package builds Debian binary packages ‘python-docutils’, ‘python-roman’, and the Python 3 equivalents. Looking at the wheezy version, it appears debian/rules was written entirely by hand, something I would like to try to avoid if possible. It also uses dh_pysupport which is considered obsolete. If I understand it correctly, it just grabs the roman.py file installed by ./setup.py and puts it into a package all by itself.
Re: multiple modules in one source
On 14 December 2014 at 15:34, Brian May br...@microcomaustralia.com.au wrote: Not sure calling it multiple distinct Python packages is correct, currently there is only one setup.py, and hence only one egg file produced. e.g. package contains setup.py module1/__init__.py module1/something.py module2/__init__.py module2/somethingelse.py To be precise with Python terminology, an importable folder (typically with an __init__.py, but there are exceptions since PEP 420) is a package, a single importable file is a module, and the thing that you get from PyPI as a single unit is a distribution, I believe. In practice, distributions are almost always called packages as well. Thomas
Re: multiple modules in one source
On 15 December 2014 at 10:46, Thomas Kluyver tho...@kluyver.me.uk wrote: To be precise with Python terminology, an importable folder (typically with an __init__.py, but there are exceptions since PEP 420) is a package, a single importable file is a module, and the thing that you get from PyPI as a single unit is a distribution, I believe. In practice, distributions are almost always called packages as well. Ok, thanks. So what upstream currently have is a single git tree, containing a single distribution, containing multiple packages. Hopefully I can use the correct terminology from now. -- Brian May br...@microcomaustralia.com.au
Re: multiple modules in one source
Hi, On Fri, Dec 12, 2014 at 1:48 AM, Ben Finney ben+deb...@benfinney.id.au wrote: An example of a single source repository which contains multiple distinct Python packages is Docutils. The ‘python-docutils’ Debian source package builds Debian binary packages ‘python-docutils’, ‘python-roman’, and the Python 3 equivalents. This is no longer the case. -- Dmitry Shachnev -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cakimphxgyg1sm3e4rp_tiagw0cfv5ms1ewtjqz2saxrlbar...@mail.gmail.com
multiple modules in one source
Hello, Just wondered if there are any examples in Debian of python packages where upstream distribute multiple distinct python modules in the one source package. I have such a package, and am wondering if I should be splitting up the source, package, or just the binary package, leaving everything combined, or maybe trying to convincing upstream that they shouldn't combine the (very much related) modules into one source. (at the present it is still very much alpha and no released version yet) Thanks -- Brian May br...@microcomaustralia.com.au
Re: multiple modules in one source
Brian May br...@microcomaustralia.com.au writes: Just wondered if there are any examples in Debian of python packages where upstream distribute multiple distinct python modules in the one source package. Just about any non-trivial Python package (and some trivial ones) in Debian will have many distinct modules. You're familiar with ‘python-django’, as just one example. Do you mean “multiple distinct Python packages”? I have such a package, and am wondering if I should be splitting up the source, package, or just the binary package, leaving everything combined, or maybe trying to convincing upstream that they shouldn't combine the (very much related) modules into one source. I think the decision of whether to keep components in a single VCS repository is an important one; the question is mostly about whether the components should always be talked about as a single body of source, with a single version string for releases. If so, then it makes sense to track them in the same VCS repository. The decision of whether components should be separately-installable is a different one, and has more to do with the utility of the components as discrete entities. If it would be useful to have one component installed but not the other associated ones, then efforts should be made to enable that. For decisions about the Debian package, the questions are likewise separate: * If it makes sense for the source to all be in the same VCS repository, I think there is no general need to split it into multiple source packages, and one Debian *source* package is fine. * If components should be separately-installable, those should be built to separate Debian *binary* packages — perhaps from the single Debian *source* package. So those are, IMO, largely distinct questions; you can answer yes to both, or only to one, or to neither. They depend on somewhat-separate factors. As for Python source distributions: the ‘distutils’ library allows nominating multiple top-level packages to build, and those can be shipped in a single ‘sdist’ and appear in a single Debian source package. Once built to a ‘bdist’, the resulting Python packages can be built to distinct Debian binary packages. Often that makes sense. An example of a single source repository which contains multiple distinct Python packages is Docutils. The ‘python-docutils’ Debian source package builds Debian binary packages ‘python-docutils’, ‘python-roman’, and the Python 3 equivalents. -- \ “We suffer primarily not from our vices or our weaknesses, but | `\from our illusions.” —Daniel J. Boorstin, historian, 1914–2004 | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85tx11g5v5@benfinney.id.au
