Skip to content
Snippets Groups Projects
  1. Mar 07, 2019
    • Gregory Szorc's avatar
      packaging: move Inno Setup core logic into a module · dc7827a9
      Gregory Szorc authored
      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
      dc7827a9
    • Gregory Szorc's avatar
      packaging: split downloading code into own module · c2237fe1
      Gregory Szorc authored
      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
      c2237fe1
    • Gregory Szorc's avatar
      packaging: establish hgpackaging package · 9da97f49
      Gregory Szorc authored
      Previously, contrib/packaging behaved as a root to a
      package directory and we had a "packagingutil" module. As I
      work more on packaging code, we'll want to have more code
      shared between different packaging tools. I think it makes
      sense to have a single package containing multiple modules
      than multiple top-level modules.
      
      This commit establishes an "hgpackaging" package by moving
      the existing packagingutil code to it.
      
      Differential Revision: https://phab.mercurial-scm.org/D6083
      9da97f49
  2. Mar 04, 2019
    • Gregory Szorc's avatar
      inno: script to automate building Inno installer · d7dc4ac1
      Gregory Szorc authored
      The official Inno installer build process is poorly documented.
      And attempting to reproduce behavior of the installer uploaded
      to www.mercurial-scm.org has revealed a number of unexpected
      behaviors.
      
      This commit attempts to improve the state of reproducibility
      of the Inno installer by introducing a Python script to
      largely automate the building of the installer.
      
      The new script (which must be run from an environment with the
      Visual C++ environment configured) takes care of producing an
      Inno installer. When run from a fresh Mercurial source checkout
      with all the proper system dependencies (the VC++ toolchain,
      Windows 10 SDK, and Inno tools) installed, it "just works."
      The script takes care of downloading all the Python
      dependencies in a secure manner and manages the build
      environment for you. You don't need any additional config
      files: just launch the script, pointing it at an existing
      Python and ISCC binary and it takes care of the rest.
      
      The produced installer creates a Mercurial installation with
      a handful of differences from the existing 4.9 installers
      (produced by someone else):
      
      * add_path.exe is missing (this was removed a few changesets ago)
      * The set of api-ms-win-core-* DLLs is different (I suspect this
        is due to me using a different UCRT / Windows version).
      * kernelbase.dll and msasn1.dll are missing.
      * There are a different set of .pyc files for dulwich,
        keyring, and pygments due to us using the latest versions of
        each.
      * We include Tcl/Tk DLLs and .pyc files (I'm not sure why these
        are missing from the existing installers).
      * We include the urllib3 and win32ctypes packages (which are
        dependencies of dulwich and pywin32, respectively). I'm not
        sure why these aren't present in the existing installers.
      * We include a different set of files for the distutils package.
        I'm not sure why. But it should be harmless.
      * We include the docutils package (it is getting picked up as
        a dependency somehow). I think this is fine.
      * We include a copy of argparse.pyc. I'm not sure why this was
        missing from existing installers.
      * We don't have a copy of sqlite3/dump.pyc. I'm not sure why. The
        SQLite C extension code only imports this module when
        conn.iterdump() is called. It should be safe to omit.
      * We include files in the email.test and test packages. The set of
        files is small and their presence should be harmless.
      
      The new script and support code is written in Python 3 because
      it is brand new and independent code and I don't believe new
      Python projects should be using Python 2 in 2019 if they have
      a choice about it.
      
      The readme.txt file has been renamed to readme.rst and overhauled
      to reflect the existence of build.py.
      
      Differential Revision: https://phab.mercurial-scm.org/D6066
      d7dc4ac1
  3. Feb 04, 2019
  4. Oct 12, 2018
  5. Aug 10, 2018
  6. Apr 20, 2018
  7. Feb 26, 2018
    • Augie Fackler's avatar
      http: drop custom http client logic · 23d12524
      Augie Fackler authored
      Eight and a half years ago, as my starter bug on code.google.com, I
      investigated a mysterious "broken pipe" error from seemingly random
      clients[0]. That investigation revealed a tragic story: the Python
      standard library's httplib was (and remains) barely functional. During
      large POSTs, if a server responds early with an error (even a
      permission denied error!) the client only notices that the server
      closed the connection and everything breaks. Such server behavior is
      implicitly legal under RFC 2616 (the latest HTTP RFC as of when I was
      last working on this), and my understanding is that later RFCs have
      made it explicitly legal to respond early with any status code outside
      the 2xx range.
      
      I embarked, probably foolishly, on a journey to write a new http
      library with better overall behavior. The http library appears to work
      well in most cases, but it can get confused in the presence of
      proxies, and it depends on select(2) which limits its utility if a lot
      of file descriptors are open. I haven't touched the http library in
      almost two years, and in the interim the Python community has
      discovered a better way[1] of writing network code. In theory some day
      urllib3 will have its own home-grown http library built on h11[2], or
      we could do that. Either way, it's time to declare our current
      confusingly-named "http2" client logic and move on. I do hope to
      revisit this some day: it's still garbage that we can't even respond
      with a 401 or 403 without reading the entire POST body from the
      client, but the goalposts on writing a new http client library have
      moved substantially. We're almost certainly better off just switching
      to requests and eventually picking up their http fixes than trying to
      live with something that realistically only we'll ever use. Another
      approach would be to write an adapter so that Mercurial can use pycurl
      if it's installed. Neither of those approaches seem like they should
      be investigated prior to a release of Mercurial that works on Python
      3: that's where the mindshare is going to be for any improvements to
      the state of the http client art.
      
      0: http://web.archive.org/web/20130501031801/http://code.google.com/p/support/issues/detail?id=2716
      1: http://sans-io.readthedocs.io/
      2: https://github.com/njsmith/h11
      
      Differential Revision: https://phab.mercurial-scm.org/D2444
      23d12524
  8. Nov 30, 2017
  9. Nov 22, 2017
  10. Jan 24, 2015
  11. Sep 26, 2017
    • David Demelier's avatar
      doc: rename README to README.rst · 1b59287a
      David Demelier authored
      Many hosting services consider README without extension as plain text. By using
      .rst extension, we bring better formatting on many services (e.g. bitbucket).
      1b59287a
  12. Oct 01, 2017
  13. Jul 21, 2017
  14. Jul 15, 2017
  15. Jul 02, 2017
  16. Jun 28, 2017
    • Adam Simpkins's avatar
      tests: use the system hg for examining the local repository · 6c113a7d
      Adam Simpkins authored
      Most test scripts use "hg" to interact with a temporary test repository.
      However a few tests also want to run hg commands to interact with the local
      repository containing the mercurial source code.  Notably, many of the
      test-check-* tests want to check local files and commit messages.
      
      These tests were previously using the version of hg being tested to query the
      source repository.  However, this will fail if the source repository requires
      extensions or other settings not supported by the version of mercurial being
      tested.  The source repository was typically initially cloned using the system
      hg installation, so we should use the system hg installation to query it.
      
      There was already a helpers-testrepo.sh script designed to help cope with
      different requirements for the source repository versus the test repositories.
      However, it only handled the evolve extension.  This new behavior works with
      any extensions that are different between the system installation and the test
      installation.
      6c113a7d
  17. May 06, 2017
  18. Apr 26, 2017
  19. May 01, 2017
  20. Apr 26, 2017
  21. May 04, 2017
    • Phil Cohen's avatar
      demandimport: add urwid.command_map to ignore list · c939fdce
      Phil Cohen authored
      The useful pudb debugger can be used with Mercurial, but its import of urwid
      fails when demandimport is enabled. Add urwid.command_map to the ignore list so
      pudb can be used with hg without disabling all of demandimport.
      c939fdce
  22. Apr 14, 2017
    • Gregory Szorc's avatar
      tests: add tests for poorly behaving HTTP server · c85f19c6
      Gregory Szorc authored
      I've spent several hours over the past few weeks investigating
      networking failures involving hg.mozilla.org. As part of this, it
      has become clear that the Mercurial client's error handling when
      it encounters network failures is far from robust.
      
      To prove this is true, I've devised a battery of tests simulating
      various network failures, notably premature connection closes. To
      achieve this, I've implemented an extension that monkeypatches the
      built-in HTTP server and hooks in at the socket level and allows
      various events to occur based on config options. For example, you
      can refuse to accept() a client socket or you can close() the socket
      after N bytes have been sent or received. The latter effectively
      simulates an unexpected connection drop (and these occur all the
      time in the real world).
      
      The new test file launches servers exhibiting various "bad" behaviors
      and points a client at them. As the many TODO comments in the test
      call attention to, Mercurial often displays unhelpful errors when
      network-related failures occur. This makes it difficult for users
      to understand what's going on and difficult for server administrators
      to pinpoint root causes without packet tracing.
      
      Upcoming patches will attempt to fix these error handling
      deficiencies.
      c85f19c6
    • Kostia Balytskyi's avatar
      windows: add win32com.shell to demandimport ignore list · 3e03a4b9
      Kostia Balytskyi authored
      Module 'appdirs' tries to import win32com.shell (and catch ImportError as an
      indication of failure) to check whether some further functionality should
      be implemented one or another way [1]. Of course, demandimport lets it down, so
      if we want appdirs to work we have to add it to demandimport's ignore list.
      
      The reason we want appdirs to work is becuase it is used by setuptools [2] to
      determine egg cache location. Only fairly recent versions of setuptools depend
      on this so people don't see this often.
      
      
      [1] https://github.com/ActiveState/appdirs/blob/master/appdirs.py#L560
      [2] https://github.com/pypa/setuptools/blob/aae0a928119d2a178882c32bded02270e30d0273/pkg_resources/__init__.py#L1369
      3e03a4b9
  23. Apr 07, 2017
  24. Apr 06, 2017
  25. Apr 03, 2017
  26. Mar 29, 2017
  27. Mar 13, 2017
  28. Mar 12, 2017
    • Katsunori FUJIWARA's avatar
      py3: add "b" prefix to string literals related to module policy · 8a17c541
      Katsunori FUJIWARA authored
      String literals without explicit prefix in __init__.py and policy.py
      are treated as unicode object on Python3, because these modules are
      loaded before setup of our specific code transformation (the later
      module is imported at the beginning of __init__.py).
      
      BTW, "modulepolicy" in __init__.py is initialized by "policy.policy".
      
      This causes issues below;
      
        - checking "policy" value in other modules causes unintentional result
      
          For example, "b'py' not in (u'c', u'py')" returns True
          unintentionally on Python3.
      
        - writing "policy" out fails at conversion from unicode to bytes
      
          62939e0148f1 fixed this issue for default code path, but "policy"
          can be overridden by HGMODULEPOLICY environment variable (it should
          be rare case for developer using Python3, though).
      
      This patch does:
      
        - add "b" prefix to all string literals, which are related to module
          policy, in modules above.
      
        - check existence of HGMODULEPOLICY, and overwrite "policy" only if
          it exists
      
          For simplicity, this patch omits checking "supports_bytes_environ",
          switching os.environ/os.environb, and so on (Yuya agreed this in
          personal talking)
      8a17c541
  29. Jan 04, 2017
  30. Dec 21, 2016
Loading