facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-11 17:27:53 +03:00
Code Issues Projects Releases Wiki Activity
a6ad29eadf
sapling/tests/test-install.t

123 lines
4.8 KiB
Perl
Raw Normal View History

tests: unify test-install
2010-08-17 16:18:59 +04:00
hg debuginstall
$ hg debuginstall
debuginstall: lowercase status messages
2012-06-12 16:18:18 +04:00
checking encoding (ascii)...
debuginstall: change showing to checking for consistency and future checking
2014-03-15 01:00:11 +04:00
checking Python executable (*) (glob)
checking Python version (2.*) (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: expose modulepolicy With this, you can check for pure easily: $ HGMODULEPOLICY=py ./hg debuginstall -T "{hgmodulepolicy}" py
2016-03-09 22:55:45 +03:00
checking module policy (*) (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: add a line about re2 availability Using re2 engine can massively speed up regexp. We make it simpler to check if it is available in a given install.
2017-11-28 02:48:36 +03:00
checking "re2" regexp engine \((available|missing)\) (re)
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": "ascii",
"encodingerror": null,
debuginstall: check C extensions only if they are loadable per policy This check is useless in pure installation and I want to make it directly import C extension modules.
2017-04-26 17:30:52 +03:00
"extensionserror": null, (no-pure !)
debuginstall: expose modulepolicy With this, you can check for pure easily: $ HGMODULEPOLICY=py ./hg debuginstall -T "{hgmodulepolicy}" py
2016-03-09 22:55:45 +03:00
"hgmodulepolicy": "*", (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
"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)
debuginstall: add a line about re2 availability Using re2 engine can massively speed up regexp. We make it simpler to check if it is available in a given install.
2017-11-28 02:48:36 +03:00
"re2": (true|false), (re)
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
"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
debuginstall: lowercase status messages
2012-06-12 16:18:18 +04:00
checking encoding (ascii)...
debuginstall: change showing to checking for consistency and future checking
2014-03-15 01:00:11 +04:00
checking Python executable (*) (glob)
checking Python version (2.*) (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: expose modulepolicy With this, you can check for pure easily: $ HGMODULEPOLICY=py ./hg debuginstall -T "{hgmodulepolicy}" py
2016-03-09 22:55:45 +03:00
checking module policy (*) (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: add a line about re2 availability Using re2 engine can massively speed up regexp. We make it simpler to check if it is available in a given install.
2017-11-28 02:48:36 +03:00
checking "re2" regexp engine \((available|missing)\) (re)
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",
"extensionserror": null, (no-pure !)
"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
checking encoding (ascii)...
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: expose modulepolicy With this, you can check for pure easily: $ HGMODULEPOLICY=py ./hg debuginstall -T "{hgmodulepolicy}" py
2016-03-09 22:55:45 +03:00
checking module policy (*) (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: add a line about re2 availability Using re2 engine can massively speed up regexp. We make it simpler to check if it is available in a given install.
2017-11-28 02:48:36 +03:00
checking "re2" regexp engine \((available|missing)\) (re)
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