[RFC] Spec for having plugins bundle their dependencies into installer

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'd like to discuss a possible spec to allow bundled plugins to define
what they need during "setup". At the moment, all of that logic is put
into bzr's setup.py, however it is going to drift based on versions of
plugins, etc.

We touched on this briefly with Mark Hammond in the past, but now that
it has become *my* job to actually maintain these things, I'd like to
make plugin author's do the work for me :).

The biggest reason is actually so that plugin author's can keep their
info up-to-date, and you don't have to worry about skew. (Packaging
bzr-svn 0.4.17 w/ bzr 1.12 should just-work, as should using 0.5.0, etc.)

What it seems to boil down to is that:

1) We need a way for the plugins to update the current state.
2) plugin/setup.py is not a good place for this, because setup.py is
doing all sorts of things running as an interactive script.
3) I'm thinking that a function in plugin/__init__.py is also not the
best place. It could work, but I sort of like having the setup code be
fairly independent of actually loading a plugin.

- From looking at the bzr setup.py code, we generally call a single
function:

def get_qbzr_py2exe_info(includes, excludes, packages):

So what I would propose is to add a new file to plugins "bzr_setup.py".
And have a single function in there called "get_py2exe_info(includes,
excludes, packages)".

So then bzr's setup.py could do:

for plugin in plugins:
  if os.path.isdir(plugin + '/bzr_setup.py'):
    import ...
    bzr_setup.get_py2exe_info(includes, excludes, packages)

I'd probably do a bit of magic with sys.modules and sys.path to avoid
having to actually load the plugin/__init__.py.


What to people (plugin authors especially) think?

The other obvious option would be to add "get_py2exe_info()" into the
plugin/__init__.py, like we do now for "test_suite()", "version_info",
and other such attributes.

I would also like to do something like this for tortoisebzr. We could
still use the "TBZR" environment flag to determine what tortoise to
load, but then we defer the rest of the updates to state to
tortoisebzr.get_py2exe_info().

The only limitation that I know of, is that we have a "bzr.iss.cog" file
that is used as a template to generate the final .iss packaging script.
(This generates the setup.exe file.)

I don't know how flexible cog is, but why not just add a:
get_cog_script() function. Such that in the end, we just concatenate all
the various strings into a single file, and run that?

Perhaps that isn't good enough, as bzr.iss.cog seems to be split into
sections, and you probably need to insert your new text into the [Files]
section.

Looking over the actual script file, it seems like we only use cog to
get a bit of scripting while generating the actual text, and it would be
trivially easy to just bring that into the "get_iss_info()" function.
Which could return a dictionary of sections, which plugins could add
their strings to.


What do people think? If there is enough agreement, I'm willing to do
the actual coding.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmVpfgACgkQJdeBCYSNAAMgtQCfXzMN2qPdviJADv4YyYzCZ40k
T2wAniyMY1wS+iy6LFnc90ZIoDvjIWJS
=7yIK
-----END PGP SIGNATURE-----