1. 20 Jan, 2020 1 commit
  2. 14 Jan, 2020 1 commit
  3. 08 Jan, 2020 1 commit
  4. 29 Dec, 2019 1 commit
  5. 23 Oct, 2019 1 commit
  6. 06 Dec, 2019 1 commit
  7. 22 Nov, 2019 1 commit
  8. 16 Nov, 2019 3 commits
    • setup: conditionalize access to `sys.dllhandle` when building extensions · 52e4bfebc4b
      This code is only run on Windows, and was crashing PyOxidizer when running in
      `setup-py-install` mode.  Now an oxidized binary can be built by simply pointing
      to setup.py.
      
      Something is slightly different now that it's not being built from a virtualenv.
      Previously, `hg version` could print to the screen, but now it aborts saying
      "Incorrect function".  But I can see the output if redirected to a file, and
      it's not complaining about missing C extensions, so I think those are loading
      now (unlike from the virtualenv).  The interesting this about this incorrect
      function output is that it failed when initially built.  I then went back and
      did a `make clean` and `make local` with py3 and then py2 to ensure I didn't
      break the existing code.  At that point I ran the oxidized executable again and
      it was able to print to the screen normally!  So I ran `pyoxidizer build` again,
      it only output the following, and then running the executable failed to output
      again:
      
          (pyO2_venv) C:\Users\Matt\hg3\hg_pyO2>pyoxidizer build
              Finished dev [unoptimized + debuginfo] target(s) in 0.12s
          packaging application into C:/Users/Matt/hg3/hg_pyO2\build\apps\hg_pyO2\x86_64-pc-windows-msvc\debug
          purging C:/Users/Matt/hg3/hg_pyO2\build\apps\hg_pyO2\x86_64-pc-windows-msvc\debug
          copying C:/Users/Matt/hg3/hg_pyO2\build\target\x86_64-pc-windows-msvc\debug\hg_pyO2.exe to
              C:/Users/Matt/hg3/hg_pyO2\build\apps\hg_pyO2\x86_64-pc-windows-msvc\debug\hg_pyO2.exe
          resolving packaging state...
          writing license for [...]
          hg_pyO2 packaged into C:/Users/Matt/hg3/hg_pyO2\build\apps\hg_pyO2\x86_64-pc-windows-msvc\debug
          executable path: C:/Users/Matt/hg3/hg_pyO2\build\apps\hg_pyO2\x86_64-pc-windows-msvc\debug\hg_pyO2.exe
      
      Differential Revision: https://phab.mercurial-scm.org/D7444
      Matt Harbison authored
    • setup: use bytes for assumed python version · 6a5dc4d767a
      Caught by PyOxidizer when hacking on Windows.
      
      # skip-blame for b'' prefixing
      
      Differential Revision: https://phab.mercurial-scm.org/D7443
      Matt Harbison authored
  9. 14 Nov, 2019 1 commit
    • help: create packages for the help text · 2e017696181
      These files need to be loaded as resources with PyOxidizer, instead of using
      filesystem representations.  AFAICT, the resource loading mechanisms only work
      for the named package given to it, and can't reach into a subdirectory.
      
      While here, the `help` directory is renamed to `helptext`.  Without this, trying
      to load external help text crashed in mercurial/help.py when importing `.i18n`,
      saying there's no `mercurial.help.i18n` module.
      
      Differential Revision: https://phab.mercurial-scm.org/D7376
      Matt Harbison authored
  10. 21 Apr, 2019 2 commits
    • setup: tweak error message for Python 3 · cd1bede340b
      We now have beta support for Python 3. In my opinion, it isn't
      yet stable enough to allow `pip install Mercurial` to work with
      Python 3 out of the box: we don't want people accidentally using
      Mercurial with Python 3 just yet.
      
      But I do think we should be more friendly about informing people
      of their options.
      
      This commit tweaks the error message that users see when running
      setup.py with Python 3. We instruct them about the current level
      of Python 3 support, point them at the wiki for more info, and
      give them instructions on how to bypass the check.
      
      As part of this, I also changed which version value is printed,
      as we were printing a named tuple before.
      
      --HG--
      branch : stable
      Gregory Szorc authored
    • setup: remove set and dict comprehensions · bd92dd3eff4
      Yuya observed in a recent review that it is worthwhile to keep
      setup.py parseable with Python 2.6 so a useful error message is
      seen when attempting to run with Python 2.6.
      
      This commit removes a set and dict comprehension so setup.py
      is parseable with Python 2.6.
      
      --HG--
      branch : stable
      Gregory Szorc authored
  11. 20 Apr, 2019 1 commit
    • setup: properly package distutils in py2exe virtualenv builds · 71d8b4d9161
      Our in-repo py2exe packaging code uses virtualenvs for managing
      dependencies. An advantage of this is that packaging is more
      deterministic and reproducible. Without virtualenvs, we need to
      install packages in the system Python install. Packages installed
      by other consumers of the system Python could leak into the Mercurial
      package.
      
      A regression from this change was that py2exe packages contained
      the virtualenv's hacked distutils modules instead of the original
      distutils modules. (virtualenv installs a hacked distutils module
      because distutils uses relative path lookups that fail when running
      from a virtualenv.)
      
      This commit introduces a workaround so py2exe packaging uses the
      original distutils modules when running from a virtualenv.
      
      With this change, `import distutils` no longer fails from py2exe
      builds produced from a virtualenv. This fixes the regression.
      Furthermore, we now include all distutils modules. Before, py2exe's
      module finding would only find modules there were explicitly
      referenced in code. So, we now package a complete copy of distutils
      instead of a partial one. This is even better than before.
      
      # no-check-commit foo_bar function name
      
      --HG--
      branch : stable
      Gregory Szorc authored
  12. 31 Jan, 2019 1 commit
  13. 31 Oct, 2018 1 commit
    • setup: explain to distutils how we write rc versions · b6bc2293cdf
      When we use a rc version number (e.g. 4.8rc0), bdist_msi is using
      distutils.StrictVersion to parse it into a tuple of numbers.
      By default, StrictVersion.version_re only recognizes [ab] for alpha/beta,
      where mercurial may use '-rc' or 'rc'.
      This change makes StrictVersion parse correctly our version numbers, so that
      bdist_msi doesn't fail on rc versions.
      
      --HG--
      branch : stable
      Paul Morelle authored
  14. 16 May, 2019 1 commit
  15. 14 Jun, 2019 2 commits
  16. 23 May, 2019 1 commit
    • rust: new rust options in setup.py · 94167e701e1
      The --rust global option turns on usage (and by default compilation)
      of the rust-cpython based mercurial.rustext.
      
      Similarly to what's previously done for zstd, there is a --no-rust
      option for the build_ext subcommand in order not to build
      mercurial.rustext, allowing for an OS distribution to prebuild it.
      
      The HGWITHRUSTEXT environment variable is still honored, and has
      the same effect as before, but now it works mostly by making
      the --rust global option defaulting to True, with some special
      cases for the direct-ffi case (see more about that below)
      
      Coincidentally, the --rust flag can also be passed from the make
      commands, like actually all global options, in the PURE variable
      
         make local PURE=--rust
      
      This feels inappropriate, though, and we should follow up with
      a proper make variable for that case.
      
      Although the direct-ffi bindings aren't directly useful any more, we
      keep them at this stage because
      
      - they provide a short prototyping path for experiments in which a C extension
        module has to call into a Rust extension. The proper way of doing that would
        be to use capsules, and it's best to wait for our pull request onto
        rust-cpython for that: https://github.com/dgrunwald/rust-cpython/pull/169
      - Build support for capsules defined in Rust will probably need to reuse
        some of what's currently in use for direct-ffi.
      Georges Racinet authored
  17. 29 May, 2019 1 commit
    • rust: module policy with importrust · 810f66b468c
      We introduce two rust+c module policies and a new
      `policy.importrust()` that makes use of them.
      
      This simple approach provides runtime switching of
      implementations, which is crucial for the performance
      measurements such as those Octobus does with ASV.
      
      It can also be useful for bug analysis.
      
      It also has the advantage of making conditionals in
      Rust callers more uniform, in particular
      abstracting over specifics like `demandimport`
      
      At this point, the build stays unchanged, with the rust-cpython based
      `rustext` module being built if HGWITHRUSTEXT=cpython.
      
      More transparency for the callers, i.e., just using
      `policy.importmod` would be a much longer term and riskier
      effort for the following reasons:
      
      1. It would require to define common module boundaries
         for the three or four cases (pure, c, rust+ext, cffi) and that
         is premature with the Rust extension currently under heavy
         development in areas that are outside the scope of the C extensions.
      2. It would imply internal API changes that are not currently wished,
         as the case of ancestors demonstrates.
      3. The lack of data or property-like attributes (tp_member
         and tp_getset) in current `rust-cpython` makes it impossible to
         achieve direct transparent replacement of pure Python classes by
         Rust extension code, meaning that the caller sometimes has to be able
         to make adjustments or provide additional wrapping.
      Georges Racinet authored
  18. 07 Jan, 2019 1 commit
  19. 19 Oct, 2018 1 commit
  20. 20 Oct, 2018 1 commit
  21. 09 Apr, 2018 2 commits
  22. 24 Feb, 2018 1 commit
    • setup: only allow Python 3 from a source checkout (issue5804) · fb39f6a8a86
      People are running `pip install Mercurial` with Python 3 and that
      is working because not everything performs a Python version
      compatibility check.
      
      Modern versions of pip do recognize the "python_requires" keyword
      (https://packaging.python.org/tutorials/distributing-packages/#python-requires)
      which we set if using setuptools. But this isn't set nor recognized
      everywhere.
      
      To prevent people from accidentally installing Mercurial with Python
      3 until Python 3 is officially supported, have setup.py fail when
      run with Python 3. But don't fail if we're running from a source
      checkout, as we don't want to anger Mercurial developers hacking
      on Python 3 nor Mercurial's test automation running from source
      checkouts. People running setup.py from source checkouts could still
      fall through a Python 3 crack. But at least the
      `pip install Mercurial` attempt will get nipped in the bud.
      
      --HG--
      branch : stable
      Gregory Szorc authored
  23. 06 Oct, 2019 1 commit
  24. 01 Oct, 2019 1 commit
    • setup: build extensions in parallel by default · f9d35f01b8b
      The build_ext distutils command in Python 3.5+ has a "parallel"
      option that controls whether to build extensions in parallel. It
      is disabled by default (None) and can be set to an integer value
      for number of cores or True to indicate use all available CPU
      cores.
      
      This commit changes our build_ext command override to set
      "parallel" to True unless a value has been provided by the caller.
      
      On my machine, this makes `python setup.py build_ext` 1-4s faster.
      It is worth noting that at this time, each individual source file
      constituting the extension is still built serially. For Mercurial,
      this means that we can't build faster than the slowest-to-build
      extension, which is the zstd extension by a long shot. This means
      that setup.py is still not very efficient at utilizing multiple
      cores. But we're better than before.
      
      Differential Revision: https://phab.mercurial-scm.org/D6923
      
      # no-check-commit because of foo_bar naming
      Gregory Szorc authored
  25. 17 Aug, 2019 1 commit
  26. 15 Aug, 2019 1 commit
  27. 17 Jul, 2018 1 commit
    • setup: allow to run setup.py with python 3 without a mercurial checkout · dbbe45ae5ad
      Some people may want to test mercurial in a python 3 environment through e.g.
      pip, in which case setup.py doesn't run in a mercurial checkout, so the hack
      in setup.py to allow python 3 cannot be overcome.
      
      This change allows a manual override with the HGPYTHON3 environment variable.
      
      Additionally, when for some reason the version is unknown (for crazy people
      like me, who have a git checkout of the mercurial repo), the version variable
      ends up being an unicode string, which fails the `isinstance(version, bytes)`
      assertion. So fix that at the same time.
      
      Differential Revision: https://phab.mercurial-scm.org/D3958
      Mike Hommey authored
  28. 21 Jan, 2018 1 commit
  29. 03 Apr, 2018 1 commit
  30. 22 Mar, 2018 1 commit
  31. 26 Mar, 2018 1 commit
  32. 05 Apr, 2019 1 commit
  33. 04 Apr, 2019 1 commit
  34. 05 Apr, 2019 1 commit
  35. 24 Oct, 2017 1 commit