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

[Augie Fackler]

Last post for a while, I'm going to run with this a bit:

I'm going to try putting module_search_path = ["$ORIGIN/extra_packages"] or 
similar, and then locally patch the scripts to drop extra stuff there. Will 
report back in a few days, perhaps after the US Thanksgiving holiday.

AF

> On Nov 19, 2020, at 12:29, Augie Fackler  wrote:
> 
> 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 > > wrote:
>> 
>> (resending to keep the list, sorry for the double-send Greg!)
>> 
>>> On Nov 18, 2020, at 18:03, Gregory Szorc >> > wrote:
>>> 
>>> On Wed, Nov 18, 2020 at 2:40 PM Augie Fackler >> > wrote:
>>> 
>>> 
>>> > On Apr 30, 2020, at 01:53, indygreg (Gregory Szorc) 
>>> > mailto:phabrica...@mercurial-scm.org>> 
>>> > wrote:
>>> > 
>>> > REVISION DETAIL
>>> >  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!)
> 

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D9342: pyoxidizer: run buildifier

[durin42 (Augie Fackler)]

durin42 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D9342

AFFECTED FILES
  rust/hgcli/pyoxidizer.bzl

CHANGE DETAILS

diff --git a/rust/hgcli/pyoxidizer.bzl b/rust/hgcli/pyoxidizer.bzl
--- a/rust/hgcli/pyoxidizer.bzl
+++ b/rust/hgcli/pyoxidizer.bzl
@@ -17,6 +17,7 @@
 if not IS_WINDOWS:
 resource.add_location = "in-memory"
 return
+
 # We use a custom resource routing policy to influence where things are 
loaded
 # from.
 #
@@ -39,6 +40,7 @@
 def make_exe(dist):
 """Builds a Rust-wrapped Mercurial binary."""
 packaging_policy = dist.make_python_packaging_policy()
+
 # Extension may depend on any Python functionality. Include all
 # extensions.
 packaging_policy.extension_module_filter = "all"
@@ -50,8 +52,10 @@
 config = dist.make_python_interpreter_config()
 config.raw_allocator = "system"
 config.run_command = RUN_CODE
+
 # We want to let the user load extensions from the file system
 config.filesystem_importer = True
+
 # We need this to make resourceutil happy, since it looks for sys.frozen.
 config.sys_frozen = True
 config.legacy_windows_stdio = True



To: durin42, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: --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  wrote:
> 
> (resending to keep the list, sorry for the double-send Greg!)
> 
>> On Nov 18, 2020, at 18:03, Gregory Szorc > > wrote:
>> 
>> On Wed, Nov 18, 2020 at 2:40 PM Augie Fackler > > wrote:
>> 
>> 
>> > On Apr 30, 2020, at 01:53, indygreg (Gregory Szorc) 
>> > mailto:phabrica...@mercurial-scm.org>> 
>> > wrote:
>> > 
>> > REVISION DETAIL
>> >  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!)

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[Bug 6438] New: mercurial always ignores binaryes (even not in .hgignore)?

[mercurial-bugs]

https://bz.mercurial-scm.org/show_bug.cgi?id=6438

Bug ID: 6438
   Summary: mercurial always ignores binaryes (even not in
.hgignore)?
   Product: Mercurial
   Version: 5.5.1
  Hardware: PC
OS: Windows
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@mercurial-scm.org
  Reporter: alexraynepe...@gmail.com
CC: mercurial-devel@mercurial-scm.org
Python Version: ---

Hallow!
works on win8, with mercurial 5.5, and 5.6 for py2 and py3.

all of them are ignore library (*.lib) files on my projects.
.hgignore not contains them. 
i can see that *.lib files with `hg stat --all`

This is realy unexpected behaviour. Is it bug or feature?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

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

[Augie Fackler]

(resending to keep the list, sorry for the double-send Greg!)

> On Nov 18, 2020, at 18:03, Gregory Szorc  > wrote:
> 
> On Wed, Nov 18, 2020 at 2:40 PM Augie Fackler  > wrote:
> 
> 
> > On Apr 30, 2020, at 01:53, indygreg (Gregory Szorc) 
> > mailto:phabrica...@mercurial-scm.org>> 
> > wrote:
> > 
> > REVISION DETAIL
> >  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!)___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel