--extra-packages-script and PyOxidizer (was: Re: D8477: packaging: support building WiX installers with PyOxidizer)

[Augie Fackler]

Okay, looking some more, I have an idea. Please shoot it down if it's bad!

Basically I think I can (for now) maintain a local patch that adds a call to `PythonExecutable.read_package_root()` and gives it our "google" extension in the packages argument. Does that sound about right?

(I'll probably poke at this after lunch, but any feedback on the merits of this hackery welcomed.)

> On Nov 19, 2020, at 11:36, Augie Fackler <raf at durin42.com> wrote:
> 
> (resending to keep the list, sorry for the double-send Greg!)
> 
>> On Nov 18, 2020, at 18:03, Gregory Szorc <gregory.szorc at gmail.com <mailto:gregory.szorc at gmail.com>> wrote:
>> 
>> On Wed, Nov 18, 2020 at 2:40 PM Augie Fackler <raf at durin42.com <mailto:raf at durin42.com>> wrote:
>> 
>> 
>> > On Apr 30, 2020, at 01:53, indygreg (Gregory Szorc) <phabricator at mercurial-scm.org <mailto:phabricator at mercurial-scm.org>> wrote:
>> > 
>> > REVISION DETAIL
>> >  https://phab.mercurial-scm.org/D8477 <https://phab.mercurial-scm.org/D8477>
>> > 
>> > AFFECTED FILES
>> >  contrib/packaging/hgpackaging/cli.py
>> >  contrib/packaging/hgpackaging/wix.py
>> >  contrib/packaging/wix/mercurial.wxs
>> > 
>> 
>> [snip other diff regions]
>> 
>> > diff --git a/contrib/packaging/hgpackaging/cli.py b/contrib/packaging/hgpackaging/cli.py
>> > --- a/contrib/packaging/hgpackaging/cli.py
>> > +++ b/contrib/packaging/hgpackaging/cli.py
>> > @@ -50,6 +50,7 @@
>> [snip misc hunks]
>> 
>> >     if extra_packages_script:
>> > +        if pyoxidizer_target:
>> > +            raise Exception(
>> > +                "pyoxidizer does not support --extra-packages-script"
>> > +            )
>> 
>> Is this a fundamental limitation, or is there just some code to write to make this? I need to inject our custom extension into the MSI we distribute to our users, and I figure this is probably roughly the way. I'm finally to the point that I appear to have the rest of the process working, so now I "just" need to wire up including the Google-custom bits.
>> 
>> The problem is that there's no easy way to pass conditional state into the Starlark execution environment outside of changing the name of the target you want to build and having different targets for different configurations.
> 
> (I haven't dug yet, so please forgive me if this is a bad idea) Would it work to have an "extra stuff" tree somewhere that PyOxidizer includes? That's pretty much what we do for the existing installer setup - that is, all we do is drop extra files in the right places and then WiX picks them up. Could we do something similar with PyOxidizer?
> 
>> One way to address this would be to expose environment variables as Starlark variables. Or a `--var key=value` syntax to register custom variables. These features may or may not have been requested in the PyOxidizer issue tracker. Both are reasonable IMO. Would you mind commenting on or filing a GitHub issue representing the feature you think works best?
> 
> I can't find anything obvious. I think my preference would be to add some sort of --var syntax so it's explicit rather than environmental. Do you have a preference?
> 
> (Searching issue trackers is hard!)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20201119/4c60ee69/attachment-0002.html>