RFC: shipping external-tree plugins

[Martin Pool]

On Mon, Jul 28, 2008 at 10:25 AM, Robert Collins
<robertc at robertcollins.net> wrote:
> So we decided at the last major get together to ship plugins from
> outside the core in the main tarball.
>
> There seem to be several necessary conditions to me:
>  - a list of plugins we want to ship
>  - a mechanism to grab them and put them on disk
>  - an automated test of the result *uninstalled* aggregate
>
> I think the easiest way to do this for now is:
>  - a list of url's to pull from during the creation of a release, which
> I propose we start off calling /BUNDLED.PLUGINS(*)
>  - change make dist to branch each url into bzrlib/plugins/
>
> Thoughts?

That sounds good to me.

As a tweak, I would say that we should perhaps call it just
'bundled_plugins' since it is not relevant to an end user installer as
COPYING, README or INSTALL is.

For packaging it may be easier to continue shipping bzr and each
plugin separately, and to handle installing some plugins by default at
the packaging level.   So would we then also ship a bzr-core tarball
as well as the bzr full release?

It might be more appropriate to keep 'make dist' producing just the
core tarball.

>  - an automated test of the result *uninstalled* aggregate

We already have a command check-dist-tarball that runs the tests from
the tarball.  I'm not sure what you mean by uninstalled here.  If you
mean without doing a real system-wide install that's true, it
currently runs 'make check' in a directory containing the unpacked
contents.  It would be useful to also test that the tarball does
install and work but we don't currently do that.

>  - change make dist to branch each url into bzrlib/plugins/

Is that enough to get them installed?  The python files will probably
be copied, but it may not be enough for anything that needs a setup.py
file run.  But at least some useful plugins don't have one..

-- 
Martin <http://launchpad.net/~mbp/>