On 05/02/15 05:36, Brian May wrote: > To try and be flexible, lets say I split up some parts of Karaage into > plugins[2]; I split them up into separate git source, hence separate > distributable and packages. This is because some plugins are not needed > by some installations, and require large dependencies (e.g. matplotlib), > of which some don't have Python 3 packages in wheezy (and not easy to > fix this due to old Python 3 in wheezy).
The way I'd typically do this would be: * one source package (upstream: git repo, tarball, etc.; RPM: spec file) per thing that has its own independent release schedule * one binary package (upstream: --disable-whatever flag? I don't know how you'd conventionally do that in Python; RPM: subpackage) per plugin with "heavy" dependencies If your reaction to "I'm using karaage-plugin-misc/1.2.4 and karaage-plugin-other/1.2.2 with karaage/1.2.3" would be "wtf, never do that" then that's probably a sign that they should be the same source package. Conversely, if you give them separate release schedules and support mixed versions, it's OK for them to be separate source packages if that's easier for you. I suspect you'd find it easier to add new features in a plugin that depend on new features in the core if the plugins were in the same source package as the core - but I don't know how often you do that, and you'd have to balance that against the work required to be able to enable/disable plugins. Binary distributions that consistently ship one binary package per source package won't be happy, but I think those distributions are already wrong, and the sooner they realise that, the better :-) (dpkg and rpm both make a more sensible structure easy.) > This worked well, it was possible to install only the plugins you > needed, and you can manually change the configuration to enable or > disable them. I don't know how you'd do selective installation in setup.py, but in an Autotools or CMake project, I'd implement this as an --enable-whatever option (or CMake variable) per plugin, defaulting to some sort of autodetection. People installing from source would get the plugins whose dependencies they had; a distribution like Debian would enable all the plugins, then split some of them (those with "heavy" dependencies) off into separate binary packages. S -- 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/54d32b70.9000...@debian.org