Thu, 07 Mar 2019 13:47:28 -0800 setup: properly install build_hgextindex for py2exe builds
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 13:47:28 -0800] rev 41917
setup: properly install build_hgextindex for py2exe builds Because the hgbuild class has a private copy of build.sub_commands, modifying build.sub_commands from this code effectively resulted in a no-op. Registering the sub-command on hgbuild actually results in the sub-command running when building Mercurial. Differential Revision: https://phab.mercurial-scm.org/D6093
Thu, 07 Mar 2019 12:15:32 -0800 setup: configure py2exe config via environment variables
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 12:15:32 -0800] rev 41916
setup: configure py2exe config via environment variables The Inno Setup and WiX installers ship a different set of packages with py2exe builds. And there are multiple WiX installer variants (e.g. TortoiseHG). Since there are multiple variants of py2exe configs and they can be defined by entities not in our repository, let's provide a mechanism for setup.py to supplement behavior via environment variables. This is slighly less hacky than a setup.cfg file IMO since the caller doesn't need to worry about mutating global state of the source directory. Differential Revision: https://phab.mercurial-scm.org/D6092
Thu, 07 Mar 2019 15:43:54 -0800 packaging: extract py2exe functionality to own module
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 15:43:54 -0800] rev 41915
packaging: extract py2exe functionality to own module py2exe builds are shared between Inno Setup and WIX. We'll want the logic for performing py2exe builds to be reusable across the code for both installers. This commit extracts the py2exe-specific functionality into its own module. There's definitely room to customize things further. This will be done in future commits, as necessary. (I'm not even sure what customizations WIX will require yet. Presumably a lot.) Differential Revision: https://phab.mercurial-scm.org/D6091
Thu, 07 Mar 2019 10:49:59 -0800 packaging: extract python exe info to own function
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 10:49:59 -0800] rev 41914
packaging: extract python exe info to own function This is generic functionality. We'll need it for WIX. As part of the port, we expose the full version and return the data as a dict. Differential Revision: https://phab.mercurial-scm.org/D6090
Thu, 07 Mar 2019 10:36:20 -0800 packaging: don't use temporary directory
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 10:36:20 -0800] rev 41913
packaging: don't use temporary directory We were no longer doing anything with it after extracting virtualenv and py2exe to the build directory. Differential Revision: https://phab.mercurial-scm.org/D6089
Thu, 07 Mar 2019 10:35:20 -0800 packaging: extract virtualenv and py2exe to build directory
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 10:35:20 -0800] rev 41912
packaging: extract virtualenv and py2exe to build directory The build directory is essentially a cache. We can extract the virtualenv and py2exe package sources to this directory. Differential Revision: https://phab.mercurial-scm.org/D6088
Thu, 07 Mar 2019 15:43:14 -0800 packaging: move Inno Setup core logic into a module
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 15:43:14 -0800] rev 41911
packaging: move Inno Setup core logic into a module Aspects of building the Inno Setup and WIX installers are shared. It will make sense for them to share code. Plus, having code in a reusable library (as opposed to a standalone script) is just a better approach. This commit moves the core logic to build the Inno Setup installer into the hgpackaging package. inno/build.py is now a simple frontend script that calls into a module to do the bulk of the work. As part of this change, I also found a typo in build() where it was referencing "iscc" instead of "iscc_exe." Because "iscc" was in the global scope via the only caller, things just happened to work before. Another benefit of always using functions and not putting global code for __main__ in the same file as library code. Differential Revision: https://phab.mercurial-scm.org/D6087
Thu, 07 Mar 2019 10:22:09 -0800 packaging: move find_vc_runtime_files() into hgpackaging.util
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 10:22:09 -0800] rev 41910
packaging: move find_vc_runtime_files() into hgpackaging.util In preparation for moving the bulk of the Inno Setup code into hgpackaging. Differential Revision: https://phab.mercurial-scm.org/D6086
Thu, 07 Mar 2019 10:20:37 -0800 packaging: move DOWNLOADS dict to hgpackaging.downloads
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 10:20:37 -0800] rev 41909
packaging: move DOWNLOADS dict to hgpackaging.downloads We'll want to keep state in sync between multiple packaging tools. It makes sense to share a central data structure defining downloads. We also change the function to return the downloads entry so callers don't have to access the global DOWNLOADS in the new location. Differential Revision: https://phab.mercurial-scm.org/D6085
Thu, 07 Mar 2019 15:42:32 -0800 packaging: split downloading code into own module
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 15:42:32 -0800] rev 41908
packaging: split downloading code into own module As we will introduce more code to support packaging, it will be useful to have download code in its own module. Differential Revision: https://phab.mercurial-scm.org/D6084
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip