<HTML><BODY><div><br>Alexander, I’ve tried your suggestion on brew update and created the issue on testing suites list, check the following.<br> <blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;">Среда, 25 марта 2020, 15:30 +03:00 от Alexander Turenko <alexander.turenko@tarantool.org>:<br> <div id=""><div class="js-helper js-readmsg-msg"><style type="text/css"></style><div><div id="style_15851394050774764725_BODY">> >> + brew update || echo | /usr/bin/ruby -e \<br>> >> + "$(curl -fsSL <a href="https://raw.githubusercontent.com/Homebrew/install/master/install" target="_blank">https://raw.githubusercontent.com/Homebrew/install/master/install</a> )"<br>> ><br>> >Why don't update formulae after installing brew?<br>><br>> The tapped formula does not exist in brew any more, though it can’t be<br>> updated.<br><br>After installing brew you'll have fresh brew, but no formulae, I guess.<br>Will the next `brew install` work? I guess, no. You need `brew update`<br>after this.</div></div></div></div></blockquote></div><div>I’ve tried to remove the brew and reinstalled it with this command, seems that all needed updates were tried to do during the installation:<br>==> Tapping homebrew/core<br>Cloning into '/usr/local/Homebrew/Library/Taps/homebrew/homebrew-core'...<br>remote: Enumerating objects: 699135, done.<br>remote: Total 699135 (delta 0), reused 0 (delta 0), pack-reused 699135<br>Receiving objects: 100% (699135/699135), 283.20 MiB | 8.49 MiB/s, done.<br>Resolving deltas: 100% (459609/459609), done.<br>Tapped 2 commands and 4942 formulae (5,205 files, 310.5MB).<br>Already up-to-date.<br><br>Also the next command with installation passed without any issues and installed all the needed packages.</div><div><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div><div class="js-helper js-readmsg-msg"><div><div><br>So it seems logical to do `[ -z "$(which brew) "] && ruby<br>brew_install_script; brew update` rather than `brew update || ruby<br>brew_install_script`.<br><br>> >From the previous review [1]:<br>> ><br>> >> > > So you added brew installation when it is not installed. Add this to the<br>> >> > > commit message at least.<br>> >> ><br>> >> > Is it possible at all for a machine that is enabled into CI? Aren't you<br>> >> > use brew to install gitlab runner?<br>> >> ><br>> >> > I’ve added the commit message about it. This change is really needed to be sure that<br>> >> > our customers can use this script too.<br>> ><br>> >Are there any customer who run our testing? I don't know anyone. Even if<br>> >one doing it, (s)he prepares an environment and invoke `make test` or<br>> >`cd test && ./test-run.py`.<br>> ><br>> >So it is the dead code. Personally I prefer to don't have dead code. If<br>> >you decided to do it, okay.<br>> ><br>> >[1]: <a href="https://lists.tarantool.org/pipermail/tarantool-patches/2020-March/015062.html" target="_blank">https://lists.tarantool.org/pipermail/tarantool-patches/2020-March/015062.html</a><br>><br>> Actually, I’ve meant that people who run on Mac hosts, like people<br>> in our group.<br><br>Developers doing `make test` or `cd test && ./test-run.py`. Nobody want<br>to run a testing script and found that something was changed in its<br>system. So I'm still on my view.<br><br>> >> + # try to install the packages either upgrade it to avoid of fails<br>> >> + # if the package already exists with the previous version<br>> >> + brew install --force ${OSX_PKGS} || brew upgrade ${OSX_PKGS}<br>> >> + pip install --force-reinstall -r test-run/requirements.txt<br>> ><br>> >--user (pip option) is not needed anymore? It was added to avoid using<br>> >of sudo or virtualenv. Is it related to a Travis CI infrastructure<br>> >change?<br>><br>> Right, but in real it was added because of gitlab-ci, for now we have<br>> well configured OSX like travis’s.<br><br>'It' -- the option? Okay so. Good piece of information to add to the<br>commit message.</div></div></div></div></blockquote></div><div>Ok, added.</div><div><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div><div class="js-helper js-readmsg-msg"><div><div><br>> >It looks a bit strance that pip w/o --user just works from 'travis'<br>> >user.<br>> You may check that testing passed with installation part without issues (check from line 8908):<br>> <a href="https://www.travis-ci.org/github/tarantool/tarantool/jobs/666683564" target="_blank">https://www.travis-ci.org/github/tarantool/tarantool/jobs/666683564</a><br><br>Okay. Yep, it seems pip assumes --user by default in Travis CI. Maybe I<br>wrongly remember that --user was added for Travis CI (AFAIR it was done<br>by Arseniy).<br><br>> >> + cd test && ./test-run.py --vardir /tmp/tnt --force $(TEST_RUN_EXTRA_PARAMS) \<br>> >> app/ app-tap/ box/ box-py/ box-tap/ engine/ engine_long/ long_run-py/ luajit-tap/ \<br>> >> replication-py/ small/ sql/ sql-tap/ swim/ unit/ vinyl/ wal_off/ xlog/ xlog-py/<br>> ><br>> >Why not to use --exclude or TEST_RUN_EXCLUDE?<br>> ><br>> >Are there any issue about disabled tests?<br>> ><br>> >Why the whole suite is going to be disabled? To save time to investigate<br>> >problems?<br>> ><br>> >When we'll investigate and enable tests rather then only disable them?<br>> >The past year trend to don't enable anything back…<br>><br>> This commit is already complete of changes and the change on the<br>> testing suites better to make in the next patch, due to the list of<br>> suites were not changed.<br><br>Let's add the info about Mac OS X testing into the relevant issue to<br>track disabled tests (AFAIR you have one, but it was about testing<br>during RPM packages build).</div></div></div></div></blockquote></div><div>Ok, sure:<br><a href="https://github.com/tarantool/tarantool/issues/4818">https://github.com/tarantool/tarantool/issues/4818</a></div><div><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div><div class="js-helper js-readmsg-msg"><div><div><br>> >From the previous review [1]:<br>> ><br>> >> > The problem with 'var' directory is not related to the new way to Python<br>> >> > 2 installation? Why everything is in one commit?<br>> >><br>> >> This commit is about OSX host setup for building and testing, so I<br>> >> think it is ok to set it here.<br>> ><br>> >It sounds as 'because something going not right, when something was<br>> >changed'. Neat reason.<br>> ><br>> >I cannot say neither 'ok', not 'not ok' for this. Okay, I can guess that<br>> >working directory is changed somehow, but why and where?<br>><br>> ‘var’ directory lays too deep at the path and the length of the path<br>> is too long for test-run.py tool which fails because of it, the<br>> solution to fix it is to use the short link for the ‘var’ directory.<br><br>Why it was okay, but becomes too long?</div></div></div></div></blockquote></div><div>Because the name of the user on the new mac mini and its home path is really long<br>echo ~ | wc -c<br> 28<br>also the path of tarantool/test/var adds.</div><div><div> </div><div data-signature-widget="container"><div data-signature-widget="content"><div>--<br>Alexander Tikhonov</div></div></div><div> </div></div></BODY></HTML>