facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-11 01:07:15 +03:00
Code Issues Projects Releases Wiki Activity
45b9cabfb3
sapling/eden/scm/tests/test-install.t

115 lines
4.4 KiB
Perl
Raw Normal View History

tests: unify test-install
2010-08-17 16:18:59 +04:00
hg debuginstall
$ hg debuginstall
encoding: replace 'ascii' with 'utf-8' automatically Summary: `ascii` was used as the default / fallback, which is not a user-friendly choice. Nowadays utf-8 dominates: - Rust stdlib is utf-8. - Ruby since 1.9 is utf-8 by default. - Python 3 is unicode by default. - Windows 10 adds utf-8 code page. Given the fact that: - Our CI sets HGENCODING to utf-8 - Nuclide passes `--encoding=utf-8` to every command. - Some people have messed up with `LC_*` and complained about hg crashes. - utf-8 is a super set of ascii, nobody complains that they want `ascii` encoding and the `utf-8` encoding messed their setup up. Let's just use `utf-8` as the default encoding. More aggressively, if someone sets `ascii` as the encoding, it's almost always a mistake. Auto-correct that to `utf-8` too. This should also make future integration with Rust easier (where it's enforced utf-8 and does not have an option to change the encoding). In the future we might just drop the flexibility of choosing customized encoding, so this diff autofixes `ascii` to `utf-8`, instead of allowing `ascii` to be set. We cannot enforce `utf-8` yet, because of Windows. Here is our encoding strategy vs the upstream's: | item | upstream | | ours | ours | | | current | ideal | current | ideal | | CLI argv | bytes | bytes | utf-8 [1] | utf-8 | | path | bytes | auto [3] | migrating [2] | utf-8 | | commit message | utf-8 | utf-8 | utf-8 | utf-8 | | bookmark name | utf-8 | utf-8 | utf-8 | utf-8 | | file content | bytes | bytes | bytes | bytes | [1]: Argv was accidentally enforced utf-8 for command-line arguments by a Rust wrapper. But it simplified a lot of things and is kind of ok: everything that can be passed as CLI arguments are utf-8: -M commit message, -b bookmark, paths, etc. There is no "file content" passed via CLI arguments. [2]: Path is controversial, because it's possible for systems to have non-utf8 paths. The upstream behavior is incorrect if a repo gets shared among different encoding systems (ex. both Linux and Windows). We have to know the encoding of paths to be able to convert them suitable for the local system. One way is to enforce UTF-8 for paths. The other is to keep encoding information stored with individual paths (like Ruby strings). The UTF-8 approach is much simpler with the tradeoff that non-utf-8 paths become unsupported, which seems to be a reasonable trade-off. [3]: See https://www.mercurial-scm.org/wiki/WindowsUTF8Plan. Reviewed By: singhsrb Differential Revision: D17098991 fbshipit-source-id: c0ff1e586a887233bd43cdb854fb3538aa9b70c2
2019-09-13 01:05:08 +03:00
checking encoding (utf-8)...
debuginstall: change showing to checking for consistency and future checking
2014-03-15 01:00:11 +04:00
checking Python executable (*) (glob)
test-install: fix py3 compatibility Summary: The test should not assert Python version is "2.*". Reviewed By: kulshrax Differential Revision: D20231781 fbshipit-source-id: 2e10c37bb4b665bc4d5d4b27329c4c2cb23d54e3
2020-03-04 04:43:09 +03:00
checking Python version (*) (glob)
debuginstall: show directory for Python lib Example new output on Windows: $ hg debuginstall checking encoding (cp1252)... checking Python lib (C:\Users\adi\hgrepos\hg-main\hg-python\lib)... checking installed modules (C:\Users\adi\hgrepos\hg-main\mercurial)... checking templates (C:\Users\adi\hgrepos\hg-main\mercurial\templates)... checking commit editor... C:\Program Files (x86)\Notepad++\notepad++.exe checking username... no problems detected on Linux: adi@kork-ubuntu64:~/hgrepos/hg-main$ ./hg debuginstall checking encoding (UTF-8)... checking Python lib (/usr/lib/python2.7)... checking installed modules (/home/adi/hgrepos/hg-main/mercurial)... checking templates (/home/adi/hgrepos/hg-main/mercurial/templates)... checking commit editor... checking username... no problems detected
2012-08-06 14:59:47 +04:00
checking Python lib (*lib*)... (glob)
commands: print security protocol support in debuginstall Over the past week I've had to instruct multiple people to run Python code to query the ssl module to see what TLS protocol support is present. I think it would be useful for `hg debuginstall` to print this info to make it easier to access and debug why Mercurial is complaining about using an insecure TLS 1.0 protocol. Ideally we'd also print the path to the CA cert bundle. But the APIs for querying that in sslutil can emit warnings, making it slightly more difficult to integrate into `hg debuginstall`. That work will have to wait for another day.
2016-10-20 01:07:11 +03:00
checking Python security support (*) (glob)
TLS 1.2 not supported by Python install; network connections lack modern security (?)
SNI not supported by Python install; may have connectivity issues with some servers (?)
debuginstall: add mercurial version
2016-05-11 01:45:45 +03:00
checking Mercurial version (*) (glob)
checking Mercurial custom build (*) (glob)
debuginstall: lowercase status messages
2012-06-12 16:18:18 +04:00
checking installed modules (*mercurial)... (glob)
debuginstall: print compression engine support Since compression engines may be provided by extensions and since not all registered compression engines may be available to use, it seems useful to provide a mechanism to see the state of known compression engines. This commit teaches `hg debuginstall` to print info on known and available compression engines.
2016-11-19 21:54:21 +03:00
checking registered compression engines (*zlib*) (glob)
checking available compression engines (*zlib*) (glob)
wireproto: advertise supported media types and compression formats This commit introduces support for advertising a server's support for media types and compression formats in accordance with the spec defined in internals.wireproto. The bulk of the new code is a helper function in wireproto.py to obtain a prioritized list of compression engines available to the wire protocol. While not utilized yet, we implement support for obtaining the list of compression engines advertised by the client. The upcoming HTTP protocol enhancements are a bit lower-level than existing tests (most existing tests are command centric). So, this commit establishes a new test file that will be appropriate for holding tests around the functionality of the HTTP protocol itself. Rounding out this change, `hg debuginstall` now prints compression engines available to the server.
2016-12-25 01:21:46 +03:00
checking available compression engines for wire protocol (*zlib*) (glob)
debuginstall: lowercase status messages
2012-06-12 16:18:18 +04:00
checking templates (*mercurial?templates)... (glob)
templates: move builtin styles to code Summary: See the previous diff (D15291676) for motivation. Basically, it's hard to keep static resources work well with 3 different kinds of deployments (buck xar, Windows zip, and python side-packages). This diff just precomputes common styles and hardcoded them in Python code. This should address a user complaint that `-T xml` does not work. Reviewed By: markbt Differential Revision: D15307457 fbshipit-source-id: de4edb0b6896b731301715abe612a31b1512b00a
2019-05-16 19:46:07 +03:00
checking default template (default)
tests: python executable should always be globbed Similar to d892d0231a82, the python executable could be python2.X, Python, pypy, or maybe something futuristic like pyston or nuitka.
2016-03-25 02:35:24 +03:00
checking commit editor... (* -c "import sys; sys.exit(0)") (glob)
debuginstall: convert to formatter commit editor now reports its editor default template is now reported a broken vi editor (vi not in path) is still not considered a problem (!!)
2016-03-09 21:58:51 +03:00
checking username (test)
debuginstall: lowercase status messages
2012-06-12 16:18:18 +04:00
no problems detected
tests: unify test-install
2010-08-17 16:18:59 +04:00
debuginstall: convert to formatter commit editor now reports its editor default template is now reported a broken vi editor (vi not in path) is still not considered a problem (!!)
2016-03-09 21:58:51 +03:00
hg debuginstall JSON
test-install: fix output on Windows See 388e9591df04.
2016-03-16 04:45:32 +03:00
$ hg debuginstall -Tjson | sed 's|\\\\|\\|g'
debuginstall: convert to formatter commit editor now reports its editor default template is now reported a broken vi editor (vi not in path) is still not considered a problem (!!)
2016-03-09 21:58:51 +03:00
[
{
debuginstall: print compression engine support Since compression engines may be provided by extensions and since not all registered compression engines may be available to use, it seems useful to provide a mechanism to see the state of known compression engines. This commit teaches `hg debuginstall` to print info on known and available compression engines.
2016-11-19 21:54:21 +03:00
"compengines": ["bz2", "bz2truncated", "none", "zlib"*], (glob)
"compenginesavail": ["bz2", "bz2truncated", "none", "zlib"*], (glob)
wireproto: advertise supported media types and compression formats This commit introduces support for advertising a server's support for media types and compression formats in accordance with the spec defined in internals.wireproto. The bulk of the new code is a helper function in wireproto.py to obtain a prioritized list of compression engines available to the wire protocol. While not utilized yet, we implement support for obtaining the list of compression engines advertised by the client. The upcoming HTTP protocol enhancements are a bit lower-level than existing tests (most existing tests are command centric). So, this commit establishes a new test file that will be appropriate for holding tests around the functionality of the HTTP protocol itself. Rounding out this change, `hg debuginstall` now prints compression engines available to the server.
2016-12-25 01:21:46 +03:00
"compenginesserver": [*"zlib"*], (glob)
templates: move builtin styles to code Summary: See the previous diff (D15291676) for motivation. Basically, it's hard to keep static resources work well with 3 different kinds of deployments (buck xar, Windows zip, and python side-packages). This diff just precomputes common styles and hardcoded them in Python code. This should address a user complaint that `-T xml` does not work. Reviewed By: markbt Differential Revision: D15307457 fbshipit-source-id: de4edb0b6896b731301715abe612a31b1512b00a
2019-05-16 19:46:07 +03:00
"defaulttemplate": "default",
debuginstall: convert to formatter commit editor now reports its editor default template is now reported a broken vi editor (vi not in path) is still not considered a problem (!!)
2016-03-09 21:58:51 +03:00
"defaulttemplateerror": null,
"defaulttemplatenotfound": "default",
tests: python executable should always be globbed Similar to d892d0231a82, the python executable could be python2.X, Python, pypy, or maybe something futuristic like pyston or nuitka.
2016-03-25 02:35:24 +03:00
"editor": "* -c \"import sys; sys.exit(0)\"", (glob)
debuginstall: convert to formatter commit editor now reports its editor default template is now reported a broken vi editor (vi not in path) is still not considered a problem (!!)
2016-03-09 21:58:51 +03:00
"editornotfound": false,
encoding: replace 'ascii' with 'utf-8' automatically Summary: `ascii` was used as the default / fallback, which is not a user-friendly choice. Nowadays utf-8 dominates: - Rust stdlib is utf-8. - Ruby since 1.9 is utf-8 by default. - Python 3 is unicode by default. - Windows 10 adds utf-8 code page. Given the fact that: - Our CI sets HGENCODING to utf-8 - Nuclide passes `--encoding=utf-8` to every command. - Some people have messed up with `LC_*` and complained about hg crashes. - utf-8 is a super set of ascii, nobody complains that they want `ascii` encoding and the `utf-8` encoding messed their setup up. Let's just use `utf-8` as the default encoding. More aggressively, if someone sets `ascii` as the encoding, it's almost always a mistake. Auto-correct that to `utf-8` too. This should also make future integration with Rust easier (where it's enforced utf-8 and does not have an option to change the encoding). In the future we might just drop the flexibility of choosing customized encoding, so this diff autofixes `ascii` to `utf-8`, instead of allowing `ascii` to be set. We cannot enforce `utf-8` yet, because of Windows. Here is our encoding strategy vs the upstream's: | item | upstream | | ours | ours | | | current | ideal | current | ideal | | CLI argv | bytes | bytes | utf-8 [1] | utf-8 | | path | bytes | auto [3] | migrating [2] | utf-8 | | commit message | utf-8 | utf-8 | utf-8 | utf-8 | | bookmark name | utf-8 | utf-8 | utf-8 | utf-8 | | file content | bytes | bytes | bytes | bytes | [1]: Argv was accidentally enforced utf-8 for command-line arguments by a Rust wrapper. But it simplified a lot of things and is kind of ok: everything that can be passed as CLI arguments are utf-8: -M commit message, -b bookmark, paths, etc. There is no "file content" passed via CLI arguments. [2]: Path is controversial, because it's possible for systems to have non-utf8 paths. The upstream behavior is incorrect if a repo gets shared among different encoding systems (ex. both Linux and Windows). We have to know the encoding of paths to be able to convert them suitable for the local system. One way is to enforce UTF-8 for paths. The other is to keep encoding information stored with individual paths (like Ruby strings). The UTF-8 approach is much simpler with the tradeoff that non-utf-8 paths become unsupported, which seems to be a reasonable trade-off. [3]: See https://www.mercurial-scm.org/wiki/WindowsUTF8Plan. Reviewed By: singhsrb Differential Revision: D17098991 fbshipit-source-id: c0ff1e586a887233bd43cdb854fb3538aa9b70c2
2019-09-13 01:05:08 +03:00
"encoding": "utf-8",
debuginstall: convert to formatter commit editor now reports its editor default template is now reported a broken vi editor (vi not in path) is still not considered a problem (!!)
2016-03-09 21:58:51 +03:00
"encodingerror": null,
revset: replace some repo.revs with repo.nodes Summary: Migrate away from some uses of revision numbers. Some dead code in discovery.py is removed. I also fixed some test issues when I run tests locally. Reviewed By: sfilipco Differential Revision: D20155399 fbshipit-source-id: bfdcb57f06374f9f27be51b0980652ef50a2c8e0
2020-02-29 04:42:44 +03:00
"extensionserror": null,
debuginstall: convert to formatter commit editor now reports its editor default template is now reported a broken vi editor (vi not in path) is still not considered a problem (!!)
2016-03-09 21:58:51 +03:00
"hgmodules": "*mercurial", (glob)
debuginstall: add mercurial version
2016-05-11 01:45:45 +03:00
"hgver": "*", (glob)
"hgverextra": "*", (glob)
debuginstall: convert to formatter commit editor now reports its editor default template is now reported a broken vi editor (vi not in path) is still not considered a problem (!!)
2016-03-09 21:58:51 +03:00
"problems": 0,
tests: python executable path should always be globbed Although this is coming in under the guise of consistency, part of the desire for this is that at least as part of the official Solaris builds, we build with a versioned python interpreter, such as "python2.7", which doesn't match "*python".
2016-03-16 01:50:57 +03:00
"pythonexe": "*", (glob)
tests: python executable should always be globbed Similar to d892d0231a82, the python executable could be python2.X, Python, pypy, or maybe something futuristic like pyston or nuitka.
2016-03-25 02:35:24 +03:00
"pythonlib": "*", (glob)
commands: print security protocol support in debuginstall Over the past week I've had to instruct multiple people to run Python code to query the ssl module to see what TLS protocol support is present. I think it would be useful for `hg debuginstall` to print this info to make it easier to access and debug why Mercurial is complaining about using an insecure TLS 1.0 protocol. Ideally we'd also print the path to the CA cert bundle. But the APIs for querying that in sslutil can emit warnings, making it slightly more difficult to integrate into `hg debuginstall`. That work will have to wait for another day.
2016-10-20 01:07:11 +03:00
"pythonsecurity": [*], (glob)
debuginstall: convert to formatter commit editor now reports its editor default template is now reported a broken vi editor (vi not in path) is still not considered a problem (!!)
2016-03-09 21:58:51 +03:00
"pythonver": "*.*.*", (glob)
"templatedirs": "*mercurial?templates", (glob)
"username": "test",
"usernameerror": null,
"vinotfound": false
}
]
tests: unify test-install
2010-08-17 16:18:59 +04:00
hg debuginstall with no username
$ HGUSER= hg debuginstall
encoding: replace 'ascii' with 'utf-8' automatically Summary: `ascii` was used as the default / fallback, which is not a user-friendly choice. Nowadays utf-8 dominates: - Rust stdlib is utf-8. - Ruby since 1.9 is utf-8 by default. - Python 3 is unicode by default. - Windows 10 adds utf-8 code page. Given the fact that: - Our CI sets HGENCODING to utf-8 - Nuclide passes `--encoding=utf-8` to every command. - Some people have messed up with `LC_*` and complained about hg crashes. - utf-8 is a super set of ascii, nobody complains that they want `ascii` encoding and the `utf-8` encoding messed their setup up. Let's just use `utf-8` as the default encoding. More aggressively, if someone sets `ascii` as the encoding, it's almost always a mistake. Auto-correct that to `utf-8` too. This should also make future integration with Rust easier (where it's enforced utf-8 and does not have an option to change the encoding). In the future we might just drop the flexibility of choosing customized encoding, so this diff autofixes `ascii` to `utf-8`, instead of allowing `ascii` to be set. We cannot enforce `utf-8` yet, because of Windows. Here is our encoding strategy vs the upstream's: | item | upstream | | ours | ours | | | current | ideal | current | ideal | | CLI argv | bytes | bytes | utf-8 [1] | utf-8 | | path | bytes | auto [3] | migrating [2] | utf-8 | | commit message | utf-8 | utf-8 | utf-8 | utf-8 | | bookmark name | utf-8 | utf-8 | utf-8 | utf-8 | | file content | bytes | bytes | bytes | bytes | [1]: Argv was accidentally enforced utf-8 for command-line arguments by a Rust wrapper. But it simplified a lot of things and is kind of ok: everything that can be passed as CLI arguments are utf-8: -M commit message, -b bookmark, paths, etc. There is no "file content" passed via CLI arguments. [2]: Path is controversial, because it's possible for systems to have non-utf8 paths. The upstream behavior is incorrect if a repo gets shared among different encoding systems (ex. both Linux and Windows). We have to know the encoding of paths to be able to convert them suitable for the local system. One way is to enforce UTF-8 for paths. The other is to keep encoding information stored with individual paths (like Ruby strings). The UTF-8 approach is much simpler with the tradeoff that non-utf-8 paths become unsupported, which seems to be a reasonable trade-off. [3]: See https://www.mercurial-scm.org/wiki/WindowsUTF8Plan. Reviewed By: singhsrb Differential Revision: D17098991 fbshipit-source-id: c0ff1e586a887233bd43cdb854fb3538aa9b70c2
2019-09-13 01:05:08 +03:00
checking encoding (utf-8)...
debuginstall: change showing to checking for consistency and future checking
2014-03-15 01:00:11 +04:00
checking Python executable (*) (glob)
test-install: fix py3 compatibility Summary: The test should not assert Python version is "2.*". Reviewed By: kulshrax Differential Revision: D20231781 fbshipit-source-id: 2e10c37bb4b665bc4d5d4b27329c4c2cb23d54e3
2020-03-04 04:43:09 +03:00
checking Python version (*) (glob)
debuginstall: show directory for Python lib Example new output on Windows: $ hg debuginstall checking encoding (cp1252)... checking Python lib (C:\Users\adi\hgrepos\hg-main\hg-python\lib)... checking installed modules (C:\Users\adi\hgrepos\hg-main\mercurial)... checking templates (C:\Users\adi\hgrepos\hg-main\mercurial\templates)... checking commit editor... C:\Program Files (x86)\Notepad++\notepad++.exe checking username... no problems detected on Linux: adi@kork-ubuntu64:~/hgrepos/hg-main$ ./hg debuginstall checking encoding (UTF-8)... checking Python lib (/usr/lib/python2.7)... checking installed modules (/home/adi/hgrepos/hg-main/mercurial)... checking templates (/home/adi/hgrepos/hg-main/mercurial/templates)... checking commit editor... checking username... no problems detected
2012-08-06 14:59:47 +04:00
checking Python lib (*lib*)... (glob)
commands: print security protocol support in debuginstall Over the past week I've had to instruct multiple people to run Python code to query the ssl module to see what TLS protocol support is present. I think it would be useful for `hg debuginstall` to print this info to make it easier to access and debug why Mercurial is complaining about using an insecure TLS 1.0 protocol. Ideally we'd also print the path to the CA cert bundle. But the APIs for querying that in sslutil can emit warnings, making it slightly more difficult to integrate into `hg debuginstall`. That work will have to wait for another day.
2016-10-20 01:07:11 +03:00
checking Python security support (*) (glob)
TLS 1.2 not supported by Python install; network connections lack modern security (?)
SNI not supported by Python install; may have connectivity issues with some servers (?)
debuginstall: add mercurial version
2016-05-11 01:45:45 +03:00
checking Mercurial version (*) (glob)
checking Mercurial custom build (*) (glob)
debuginstall: lowercase status messages
2012-06-12 16:18:18 +04:00
checking installed modules (*mercurial)... (glob)
debuginstall: print compression engine support Since compression engines may be provided by extensions and since not all registered compression engines may be available to use, it seems useful to provide a mechanism to see the state of known compression engines. This commit teaches `hg debuginstall` to print info on known and available compression engines.
2016-11-19 21:54:21 +03:00
checking registered compression engines (*zlib*) (glob)
checking available compression engines (*zlib*) (glob)
wireproto: advertise supported media types and compression formats This commit introduces support for advertising a server's support for media types and compression formats in accordance with the spec defined in internals.wireproto. The bulk of the new code is a helper function in wireproto.py to obtain a prioritized list of compression engines available to the wire protocol. While not utilized yet, we implement support for obtaining the list of compression engines advertised by the client. The upcoming HTTP protocol enhancements are a bit lower-level than existing tests (most existing tests are command centric). So, this commit establishes a new test file that will be appropriate for holding tests around the functionality of the HTTP protocol itself. Rounding out this change, `hg debuginstall` now prints compression engines available to the server.
2016-12-25 01:21:46 +03:00
checking available compression engines for wire protocol (*zlib*) (glob)
debuginstall: lowercase status messages
2012-06-12 16:18:18 +04:00
checking templates (*mercurial?templates)... (glob)
templates: move builtin styles to code Summary: See the previous diff (D15291676) for motivation. Basically, it's hard to keep static resources work well with 3 different kinds of deployments (buck xar, Windows zip, and python side-packages). This diff just precomputes common styles and hardcoded them in Python code. This should address a user complaint that `-T xml` does not work. Reviewed By: markbt Differential Revision: D15307457 fbshipit-source-id: de4edb0b6896b731301715abe612a31b1512b00a
2019-05-16 19:46:07 +03:00
checking default template (default)
tests: python executable should always be globbed Similar to d892d0231a82, the python executable could be python2.X, Python, pypy, or maybe something futuristic like pyston or nuitka.
2016-03-25 02:35:24 +03:00
checking commit editor... (* -c "import sys; sys.exit(0)") (glob)
debuginstall: lowercase status messages
2012-06-12 16:18:18 +04:00
checking username...
ui: suggest config --edit when no username is set
2014-02-28 00:46:29 +04:00
no username supplied
Merge with stable
2010-08-30 15:00:22 +04:00
(specify a username in your configuration file)
tests: unify test-install
2010-08-17 16:18:59 +04:00
1 problems detected, please check your install!
tests: add exit codes to unified tests
2010-09-17 02:51:32 +04:00
[1]
debuginstall: expand the editor path before searching for it (issue4380) The editor launches without expanding the path with commits because the shell does that for us. If the path isn't an executable, the expanded path is displayed, which is probably more useful than the unexpanded path. For example, in cmd.exe, '~' expands to C:\Users\$user. But it expands to C:/mingw/msys/1.0/home/$user in MinGW.
2015-05-01 06:02:52 +03:00
debuginstall: use codecs.lookup() to detect invalid encoding encoding.fromlocal() never tries to decode an ascii string since 3cb2361c60fc, and there's no universal non-ascii string which can be decoded as any valid character set.
2017-09-07 16:27:23 +03:00
hg debuginstall with invalid encoding
$ HGENCODING=invalidenc hg debuginstall | grep encoding
checking encoding (invalidenc)...
unknown encoding: invalidenc
debuginstall: do not pass exception object to formatter (issue5676)
2017-09-07 16:36:54 +03:00
exception message in JSON
$ HGENCODING=invalidenc HGUSER= hg debuginstall -Tjson | grep error
"defaulttemplateerror": null,
"encodingerror": "unknown encoding: invalidenc",
revset: replace some repo.revs with repo.nodes Summary: Migrate away from some uses of revision numbers. Some dead code in discovery.py is removed. I also fixed some test issues when I run tests locally. Reviewed By: sfilipco Differential Revision: D20155399 fbshipit-source-id: bfdcb57f06374f9f27be51b0980652ef50a2c8e0
2020-02-29 04:42:44 +03:00
"extensionserror": null,
debuginstall: do not pass exception object to formatter (issue5676)
2017-09-07 16:36:54 +03:00
"usernameerror": "no username supplied",
debuginstall: expand the editor path before searching for it (issue4380) The editor launches without expanding the path with commits because the shell does that for us. If the path isn't an executable, the expanded path is displayed, which is probably more useful than the unexpanded path. For example, in cmd.exe, '~' expands to C:\Users\$user. But it expands to C:/mingw/msys/1.0/home/$user in MinGW.
2015-05-01 06:02:52 +03:00
path variables are expanded (~ is the same as $TESTTMP)
$ mkdir tools
$ touch tools/testeditor.exe
#if execbit
$ chmod 755 tools/testeditor.exe
#endif
$ hg debuginstall --config ui.editor=~/tools/testeditor.exe
encoding: replace 'ascii' with 'utf-8' automatically Summary: `ascii` was used as the default / fallback, which is not a user-friendly choice. Nowadays utf-8 dominates: - Rust stdlib is utf-8. - Ruby since 1.9 is utf-8 by default. - Python 3 is unicode by default. - Windows 10 adds utf-8 code page. Given the fact that: - Our CI sets HGENCODING to utf-8 - Nuclide passes `--encoding=utf-8` to every command. - Some people have messed up with `LC_*` and complained about hg crashes. - utf-8 is a super set of ascii, nobody complains that they want `ascii` encoding and the `utf-8` encoding messed their setup up. Let's just use `utf-8` as the default encoding. More aggressively, if someone sets `ascii` as the encoding, it's almost always a mistake. Auto-correct that to `utf-8` too. This should also make future integration with Rust easier (where it's enforced utf-8 and does not have an option to change the encoding). In the future we might just drop the flexibility of choosing customized encoding, so this diff autofixes `ascii` to `utf-8`, instead of allowing `ascii` to be set. We cannot enforce `utf-8` yet, because of Windows. Here is our encoding strategy vs the upstream's: | item | upstream | | ours | ours | | | current | ideal | current | ideal | | CLI argv | bytes | bytes | utf-8 [1] | utf-8 | | path | bytes | auto [3] | migrating [2] | utf-8 | | commit message | utf-8 | utf-8 | utf-8 | utf-8 | | bookmark name | utf-8 | utf-8 | utf-8 | utf-8 | | file content | bytes | bytes | bytes | bytes | [1]: Argv was accidentally enforced utf-8 for command-line arguments by a Rust wrapper. But it simplified a lot of things and is kind of ok: everything that can be passed as CLI arguments are utf-8: -M commit message, -b bookmark, paths, etc. There is no "file content" passed via CLI arguments. [2]: Path is controversial, because it's possible for systems to have non-utf8 paths. The upstream behavior is incorrect if a repo gets shared among different encoding systems (ex. both Linux and Windows). We have to know the encoding of paths to be able to convert them suitable for the local system. One way is to enforce UTF-8 for paths. The other is to keep encoding information stored with individual paths (like Ruby strings). The UTF-8 approach is much simpler with the tradeoff that non-utf-8 paths become unsupported, which seems to be a reasonable trade-off. [3]: See https://www.mercurial-scm.org/wiki/WindowsUTF8Plan. Reviewed By: singhsrb Differential Revision: D17098991 fbshipit-source-id: c0ff1e586a887233bd43cdb854fb3538aa9b70c2
2019-09-13 01:05:08 +03:00
checking encoding (utf-8)...
debuginstall: expand the editor path before searching for it (issue4380) The editor launches without expanding the path with commits because the shell does that for us. If the path isn't an executable, the expanded path is displayed, which is probably more useful than the unexpanded path. For example, in cmd.exe, '~' expands to C:\Users\$user. But it expands to C:/mingw/msys/1.0/home/$user in MinGW.
2015-05-01 06:02:52 +03:00
checking Python executable (*) (glob)
checking Python version (*) (glob)
checking Python lib (*lib*)... (glob)
commands: print security protocol support in debuginstall Over the past week I've had to instruct multiple people to run Python code to query the ssl module to see what TLS protocol support is present. I think it would be useful for `hg debuginstall` to print this info to make it easier to access and debug why Mercurial is complaining about using an insecure TLS 1.0 protocol. Ideally we'd also print the path to the CA cert bundle. But the APIs for querying that in sslutil can emit warnings, making it slightly more difficult to integrate into `hg debuginstall`. That work will have to wait for another day.
2016-10-20 01:07:11 +03:00
checking Python security support (*) (glob)
TLS 1.2 not supported by Python install; network connections lack modern security (?)
SNI not supported by Python install; may have connectivity issues with some servers (?)
debuginstall: add mercurial version
2016-05-11 01:45:45 +03:00
checking Mercurial version (*) (glob)
checking Mercurial custom build (*) (glob)
debuginstall: expand the editor path before searching for it (issue4380) The editor launches without expanding the path with commits because the shell does that for us. If the path isn't an executable, the expanded path is displayed, which is probably more useful than the unexpanded path. For example, in cmd.exe, '~' expands to C:\Users\$user. But it expands to C:/mingw/msys/1.0/home/$user in MinGW.
2015-05-01 06:02:52 +03:00
checking installed modules (*mercurial)... (glob)
debuginstall: print compression engine support Since compression engines may be provided by extensions and since not all registered compression engines may be available to use, it seems useful to provide a mechanism to see the state of known compression engines. This commit teaches `hg debuginstall` to print info on known and available compression engines.
2016-11-19 21:54:21 +03:00
checking registered compression engines (*zlib*) (glob)
checking available compression engines (*zlib*) (glob)
wireproto: advertise supported media types and compression formats This commit introduces support for advertising a server's support for media types and compression formats in accordance with the spec defined in internals.wireproto. The bulk of the new code is a helper function in wireproto.py to obtain a prioritized list of compression engines available to the wire protocol. While not utilized yet, we implement support for obtaining the list of compression engines advertised by the client. The upcoming HTTP protocol enhancements are a bit lower-level than existing tests (most existing tests are command centric). So, this commit establishes a new test file that will be appropriate for holding tests around the functionality of the HTTP protocol itself. Rounding out this change, `hg debuginstall` now prints compression engines available to the server.
2016-12-25 01:21:46 +03:00
checking available compression engines for wire protocol (*zlib*) (glob)
debuginstall: expand the editor path before searching for it (issue4380) The editor launches without expanding the path with commits because the shell does that for us. If the path isn't an executable, the expanded path is displayed, which is probably more useful than the unexpanded path. For example, in cmd.exe, '~' expands to C:\Users\$user. But it expands to C:/mingw/msys/1.0/home/$user in MinGW.
2015-05-01 06:02:52 +03:00
checking templates (*mercurial?templates)... (glob)
templates: move builtin styles to code Summary: See the previous diff (D15291676) for motivation. Basically, it's hard to keep static resources work well with 3 different kinds of deployments (buck xar, Windows zip, and python side-packages). This diff just precomputes common styles and hardcoded them in Python code. This should address a user complaint that `-T xml` does not work. Reviewed By: markbt Differential Revision: D15307457 fbshipit-source-id: de4edb0b6896b731301715abe612a31b1512b00a
2019-05-16 19:46:07 +03:00
checking default template (default)
tests: python executable should always be globbed Similar to d892d0231a82, the python executable could be python2.X, Python, pypy, or maybe something futuristic like pyston or nuitka.
2016-03-25 02:35:24 +03:00
checking commit editor... (* -c "import sys; sys.exit(0)") (glob)
debuginstall: convert to formatter commit editor now reports its editor default template is now reported a broken vi editor (vi not in path) is still not considered a problem (!!)
2016-03-09 21:58:51 +03:00
checking username (test)
debuginstall: expand the editor path before searching for it (issue4380) The editor launches without expanding the path with commits because the shell does that for us. If the path isn't an executable, the expanded path is displayed, which is probably more useful than the unexpanded path. For example, in cmd.exe, '~' expands to C:\Users\$user. But it expands to C:/mingw/msys/1.0/home/$user in MinGW.
2015-05-01 06:02:52 +03:00
no problems detected
tests: add coverage to ensure Wix tracks 'help' and 'templates' files This would have caught the problem fixed by 47bcbe06a48d. There are other *.wxs files that can be checked, but they appear to be more complicated. For example, locale.wxs has what appears to be foreach loop support, as well as variable substitution. By checking `hg files` to determine tracked file, this is able to avoid false failures when other junk is present in the filesystem, like *.orig files. I can't tell if the map-cmdline.status file is not included on purpose, but I don't see the purpose of excluding it. The missing help files seem reasonable for Windows.
2015-09-14 05:54:51 +03:00
Reference in New Issue Copy Permalink