[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: multiple modules in one source



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


Reply to: