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

[Mark Hammond]

On 14/02/2009 3:55 AM, John Arbash Meinel wrote:

> 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.

I'm not so sure about that for the specific requirements being discussed 
here.  Most setup.py files of interest are already doing nothing other 
than setting themselves up as a plugin for bzr in some form.  Asking 
such scripts to add an if __name__=='__main__' block is no less burden 
than asking them to add another file.

Further, the existing setup.py probably *already* does other stuff 
critical for making the plugin work - eg, building docs, creating 
localizations, etc.  So in the general case you would need to invoke 
setup.py *and* this new script which seems to create complexity.

So I'd vote for asking plugin authors to make slight adjustments to 
their setup.py, and arrange so that when this new entry point is 
invoked, *everything* is automatically built - ie, remove the 
requirement to run their external setup.py manually separately.


> 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)".

I think this signature will be too narrow - eg, I believe 'data_files' 
at least will be needed today and in the future *any* py2exe option is 
fair game.  How about passing a dict in which conforms with the 
py2exe_options dict we finally pass to py2exe?  Obviously this will 
change things a little - ie, we would pre-create the dict before calling 
these plugin functions.

> What to people (plugin authors especially) think?

I think its a great idea!

> 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 agree this is the least desirable option; setup info should be 
external from the plugin runtime code.

> 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?

I doubt that will work in the general case as the setup script has many 
sections of its own.  I think the easiest and best may be to have the 
script provide a list of files it needs installed, and we generate the 
[Files] (spelling?) section of the .ISS file from the complete list. 
The list would almost certainly need to be tuples of 
(relative_in_filename, relative_out_filename).

This would mean we are still stuck with hand-editing the special cases, 
such as the toirtoiseoverlays .msi installation, but I think that will 
be the special case - most bzr plugins can work just fine simply by 
having their built files plonked into the correct location.

>
> 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.

I doubt that would really work - eg, the inno callback functions would 
be a problem - only 1 such function can exist.  As mentioned, I think 
that in practice only tortoise has special requirements here.

Also, in the longer term, Inno may turn out to be a liability; a .MSI 
installer is probably ideal, especially when we get to the point where 
people would like to roll out a bzr installation into a corporation 
using 'group policies' and other magic used in such environments.

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

I think it is a great idea, and that the current setup we have is 
probably all the complexity we need to design for - I don't see real 
advantage in trying to make this truly generic for the Inno side of the 
world.

Cheers,

Mark