Make the chocolatey install more robust?

[yaxu]

There seem to be two main problems

• ghc install
• SuperCollider quark install

The former problem is a very long standing bug in windows haskell platform installer (https://github.com/haskell/haskell-platform/issues/324), which means it's not able to install packages that require compilation. It's fixed in a new installer, but that's not yet released. https://github.com/haskell/haskell-platform/issues/320#issuecomment-531089841 Hopefully that'll happen soon.

The second problem is to do with getting paths right with some manual git clones of the Quarks.

I think better to get sclang to do the installation. This is possible by piping the following into sclang on the commandline:

Quarks.install("https://github.com/supercollider-quarks/Vowel.git");
Quarks.install("https://github.com/musikinformatik/SuperDirt.git");
Quarks.install("https://github.com/musikinformatik/Dirt-Samples.git");

[Mistuke]

Chocolatey packages are unrelated to haskell platform though, they install only the thing on the box.

If you want to install e.g. network you need to install msys2 as well (unless you're using appveyor which has it pre-installed).

Anyway the cabal 3.0 chocolatey package is able to configure the paths automatically if you also install msys2. It won't however be able to correct a broken config from another install.

So to build network you need choco install ghc msys2 or use the haskell-dev package. https://chocolatey.org/packages/haskell-dev

[yaxu]

Thanks so much for clearing this up @mistuke! I can't tell you how much trouble we've had with this.. I guess changing the dependency in tidal to haskell-dev is all we need to do. Thanks again!

[Mistuke]

The configuration part is new in the cabal 3.0 package. So if it doesn't work out of the box for you let me know and I'll investigate :)

[yaxu]

The haskell-dev package seems to have problems at the moment https://chocolatey.org/packages/haskell-dev

For now I bumped the versions on all the dependencies (chocolatey can't do version ranges?), hopefully that'll fix things with msys2: https://github.com/tidalcycles/tidal-chocolatey/commit/03b6db01d40801082c7397cb4b9900db301e197b

I also added an sclang script for installing all the quarks: https://github.com/tidalcycles/tidal-chocolatey/commit/964e468a486bc69f03a674eeb53ec7f093038022

• updated this script to run it: https://github.com/tidalcycles/tidal-chocolatey/commit/67a5b50ed273f1de0b10a30fb431df4aceb57ea0

I also reinstated the atom plugin install and switched to cabal v2-install.

I haven't actually tested this yet, but if/when it all checks out, @kindohm what would the process be for updating this on chocolatey?

(Sorry this should have been a PR rather than direct commits..)

[yaxu]

Currently not working because sclang isn't in the path..

[yaxu]

@Mistuke I've been trying to get this working but no joy. I have the latest chocolatey packages of msys2 and ghc installed and cabal install network but getting the familiar error:

PS D:\alex\tidal-chocolatey\tidal\tools> cabal install network --lib
Resolving dependencies...
Build profile: -w ghc-8.8.1 -O1
In order, the following will be built (use -v for more details):
 - process-1.6.6.0 (lib:process) (requires build)
 - hsc2hs-0.68.6 (exe:hsc2hs) (requires build)
 - network-3.1.1.0 (lib:network) (requires build)
Starting     process-1.6.6.0 (all, legacy fallback)

Failed to build process-1.6.6.0. The failure occurred during the configure
step.
Build log (
C:\Users\lxyxp\AppData\Roaming\cabal\logs\ghc-8.8.1\process-1.6.6.0-2102a9c8572c01ff7a6b0d7a8ebe7378c0c04cb9.log
):
Configuring process-1.6.6.0...
cabal.exe: The package has a './configure' script. If you are on Windows, This
requires a Unix compatibility toolchain such as MinGW+MSYS or Cygwin. If you
are not on Windows, ensure that an 'sh' command is discoverable in your path.

cabal.exe: Failed to build process-1.6.6.0 (which is required by
network-3.1.1.0). See the build log above for details.

[yaxu]

With https://github.com/tidalcycles/tidal-chocolatey/commit/5e8923aae812fd43b3f4dd7650b188307b561a26, sclang is running fine.

[Mistuke]

Can you confirm that your cabal version is 3.0.0.0?

If so can you paste the output of cabal user-config diff?

[yaxu]

Yes @mistuke, it's 3.0.0.0:

PS C:\WINDOWS\system32> ghc-pkg list Cabal
C:\ProgramData\chocolatey\lib\ghc\tools\ghc-8.8.1\lib\package.conf.d
    Cabal-3.0.0.0

Here's the output of cabal user-config diff:

+ extra-include-dirs: C:\tools\msys64\mingw64\include
+ extra-lib-dirs: C:\tools\msys64\mingw64\lib
- extra-prog-path: C:\Users\lxyxp\AppData\Roaming\cabal\bin
+ extra-prog-path: C:\tools\msys64\usr\bin;C:\tools\msys64\mingw64\bin;C:\Users\lxyxp\AppData\Roaming\cabal\bin
+ install-method: copy
+ symlink-bindir: C:\Users\lxyxp\AppData\Roaming\cabal\bin

[yaxu]

I tried cleaning up and starting again by removing ghc and cabal from C:\Users\lxyxp\AppData\Roaming. That didn't help, and cabal user-config diff then returned nothing.

I thought reinstalling ghc with choco install --force ghc might help, but tried that with no change. cabal user-config diff still returns nothing.

However I found a windows partition on my laptop, and it works fine there.

[Mistuke]

Yeah that config was damaged

You can fix your configuration by first replacing it with the default one

cabal user-config init -f

and then reinstall the choco package to recreate the config

choco install cabal --force

It's not the GHC package that contains the configuration code, it's cabal.

[yaxu]

Aha that makes sense, and what's more, things are compiling now. Thanks again @Mistuke!

I may well just be misunderstanding the new cabal stuff, but I still can't load these modules though.

I do cabal install tidal --lib, which looks to install fine, but then ghc-pkg list tidal doesn't find anything, and import Sound.Tidal.Context doesn't work within ghci. I get the same on both windows partitions I have.

[Mistuke]

cabal now defaults to v2 by default. Which means it uses nix store like storage by default.

see https://www.haskell.org/cabal/users-guide/nix-local-build.html#cabal-v2-install, which means ghc-pkg list doesn't show them unless you tell ghc-pkg where to look for the package store.

what you probably want is cabal repl --build-depends="tidal" or similar. That or when installing use --write-ghc-environment-files=always to write a ghci environment file and then I believe ghci should pick it up.

[Mistuke]

The haskell-dev package seems to have problems at the moment https://chocolatey.org/packages/haskell-dev

The package itself is fine, but chocolatey's servers are having DNS issues.

For now I bumped the versions on all the dependencies (chocolatey can't do version ranges?),

They do, chocolatey uses NuGet as it's package format, this is how ranges work https://docs.microsoft.com/en-us/nuget/concepts/package-versioning

[yaxu]

That's strange.. cabal v2-install tidal --lib has worked fine for me up until now. Is new behaviour?

I couldn't get --write-ghc-environment-files=always to do the job, but cabal v1-install tidal works fine, I might stick with that for now.

Most tidal users are non-programmers so a simple, global library install works well for them.

[Mistuke]

hmm tbh I'm not too sure about the v2- workflow yet myself. I often get lost amongst all the options :) But it does seem you have a working install now.

[Mistuke]

That's strange.. cabal v2-install tidal --lib has worked fine for me up until now. Is new behaviour?

I do remember there being a change to the defaults after some people didn't want the environment files to be on by default. I don't recall if GHCi was also changes to not read them by default. which would explain why it didn't work for you.

[yaxu]

Heh thanks @mistuke, glad it's not just me!

@hvr do you have a moment to offer advice here.. I ideally need to be able to install the tidal library so that if I run ghci without any commandline options, the library will be available to it.

I'm trying this sort of thing:

cabal install tidal-1.4.3 --force-reinstalls --lib --write-ghc-environment-file
s=always

.. but that doesn't seem to be reinstalling anything.

The reason for this is that there are a range of editor plugins for tidal that launch ghci without arguments, and it'd be a long process to update them all, with a lot of confused end users along the way.

[hvr]

@Mistuke @yaxu first off, the setting of write-ghc-environment-files should have no impact at all (I tried on Linux v2-install --lib with --write-ghc-environment-files=never and the env-file was created as expected in the target location).

Since things work as intended on Linux, the thing I'm wondering now is whether

1. The environment file is created on Windows (for reference, on Linux it's supposed to be created in a folder such as $HOME/.ghc/x86_64-linux-8.6.5/environments/default -- this is also the file that sometimes needs to be manually removed to workaround a bug in cabal when it refuses to cabal install --lib due to self-inflicted constraint-failures due to prior installs)
2. whether GHC on Windows searches in the proper location for the $HOME-wide environment files

I don't have a suitable windows system right now; so maybe @Mistuke could help debug this...? :-)

[kindohm]

I attempted to publish the new package based on @yaxu's changes, but the package is failing automated testing on chocolatey.org because apm is not on the path.

If anyone has a quick answer about how to get the path to where Atom and apm are installed (I don't think it's in Program Files, like sclang is, see https://github.com/tidalcycles/tidal-chocolatey/blob/master/tidal/tools/chocolateyinstall.ps1#L5) then I can make the quick change and re-publish. Otherwise I will need to research this a bit in order to make the right change.

[kindohm]

Added apm to path with $env:localappdata and re-submitted.

[yaxu]

I tweaked the path to apm and resubmitted. It seems people can install it without it being approved

Here's a first attempt at installation instructions: https://tidalcycles.org/index.php/Windows_choco_install

[yaxu]

The automated test failed: https://gist.github.com/choco-bot/5a6b3f8400a25ece51f783a8acdd8dc1 https://chocolatey.org/packages/TidalCycles/1.4.3

It seems to be a network error, just as with @mistuke's problem with the haskell-dev package https://chocolatey.org/packages/haskell-dev

But strangely web searches for the error aren't turning up anything useful.. I guess I'll just re-run the test.

2019-10-09 05:00:04,961 1304 [WARN ] - [NuGet] Could not connect to the feed specified at 'https://chocolatey.org/api/v2/'. Please verify that the package source (located in the Package Manager Settings) is valid and ensure your network connectivity.
2019-10-09 05:00:04,961 1304 [ERROR] - TidalCycles not installed. An error occurred during installation:
Unable to resolve dependency 'chocolatey-core.extension (= 1.3.3)'.

[Mistuke]

Yeah, I've been going back and forth with them on various support channels for a while now as haskell-dev has been having this issue for a month+. They are actively looking into it, but so far nothing. The free community based stuff is probably not a priority :) so all we can do is wait..

[yaxu]

It ran this time, but with another failure - not finding apm again, hmm. https://gist.github.com/choco-bot/de8cd0c8e748655dbf95e64bdf163314

[Mistuke]

So if that's being installed by another chocolatey package. Why does calling refreshenv inside your script not pull it on the path?

[yaxu]

@Mistuke I'm getting positive reports from end-users that the install works, so it's a little strange that it doesn't work on the test server. AFAICT, atom and apm don't get added to the system path. However in the chocolatey script we add it to the current environment (along with the path to the supercollider synthesis system) like this:

$scpath = Join-Path $env:programfiles "SuperCollider-3.9.3"
$apmpath = Join-Path $env:localappdata "atom\bin"
$env:Path = [System.Environment]::GetEnvironmentVariable("Path","Machine") + ";" + [System.Environment]::GetEnvironmentVariable("Path","User") + ";" + $scpath + ";" + $apmpath

That seems to work, so don't know what's going on here..

[kindohm]

The only thing I can think of is that the path $env:localappdata\atom\bin does not actually exist on the Chocolatey test server, and that Atom gets installed somewhere else (e.g. not in c:\users\<user>\App Data\local).

I'm not sure how to proceed without making some significant debug edits to the install script to see what is in the $env:localappdata path during install on the test server:

get-childitem $env:localappdata

If Atom is there, then I'm not sure what the issue is. If Atom is not there, then we'll probably need to do some more console output debugging to figure out where it is on the test server.

[Mistuke]

https://github.com/chocolatey-community/chocolatey-test-environment/blob/master/ReadMe.md

You can replicate the test env locally if you're inclined.

[yaxu]

@kindohm Hmm, the log says this for atom: Software installed to 'C:\Users\Administrator\AppData\Local\atom'

Further based on the sc3plugins location, C:\Users\Administrator\AppData\Local does seem to be the value of LOCALAPPDATA

I'll try adding that trace line though..

[yaxu]

I've been trying to get the test environment running under linux mint as suggested by @mistuke: https://github.com/chocolatey-community/chocolatey-test-environment

No luck, it just won't start. Could someone else have a go please?

[yaxu]

Here's the error I get..

alex@stanage:~/src/chocolatey-test-environment$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'ferventcoder/win2012r2-x64-nocm' is up to date...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 5985 (guest) => 5985 (host) (adapter 1)
    default: 3389 (guest) => 3389 (host) (adapter 1)
    default: 22 (guest) => 2222 (host) (adapter 1)
    default: 5986 (guest) => 55986 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
#<Thread:0x000055de213429e8@/home/alex/.vagrant.d/gems/2.5.1/gems/logging-2.2.2/lib/logging/diagnostic_context.rb:471 run> terminated with exception (report_on_exception is true):
Traceback (most recent call last):
    109: from /home/alex/.vagrant.d/gems/2.5.1/gems/logging-2.2.2/lib/logging/diagnostic_context.rb:474:in `block in create_with_logging_context'
    108: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run'
    107: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/machine.rb:188:in `action'
    106: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/machine.rb:188:in `call'
    105: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/environment.rb:592:in `lock'
    104: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/machine.rb:202:in `block in action'
    103: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/machine.rb:227:in `action_raw'
    102: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/runner.rb:66:in `run'
    101: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/util/busy.rb:19:in `busy'
    100: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/runner.rb:66:in `block in run'
     99: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/builder.rb:116:in `call'
     98: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     97: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/plugins/providers/virtualbox/action/check_virtualbox.rb:17:in `call'
     96: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     95: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/builtin/call.rb:53:in `call'
     94: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/runner.rb:66:in `run'
     93: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/util/busy.rb:19:in `busy'
     92: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/runner.rb:66:in `block in run'
     91: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/builder.rb:116:in `call'
     90: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     89: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
     88: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     87: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
     86: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     85: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
     84: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     83: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/builtin/call.rb:53:in `call'
     82: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/runner.rb:66:in `run'
     81: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/util/busy.rb:19:in `busy'
     80: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/runner.rb:66:in `block in run'
     79: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/builder.rb:116:in `call'
     78: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     77: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
     76: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     75: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
     74: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     73: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/plugins/providers/virtualbox/action/check_virtualbox.rb:17:in `call'
     72: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     71: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
     70: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     69: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/builtin/box_check_outdated.rb:79:in `call'
     68: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     67: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/builtin/call.rb:53:in `call'
     66: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/runner.rb:66:in `run'
     65: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/util/busy.rb:19:in `busy'
     64: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/runner.rb:66:in `block in run'
     63: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/builder.rb:116:in `call'
     62: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     61: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
     60: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     59: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/builtin/call.rb:53:in `call'
     58: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/runner.rb:66:in `run'
     57: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/util/busy.rb:19:in `busy'
     56: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/runner.rb:66:in `block in run'
     55: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/builder.rb:116:in `call'
     54: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     53: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
     52: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     51: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/builtin/call.rb:53:in `call'
     50: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/runner.rb:66:in `run'
     49: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/util/busy.rb:19:in `busy'
     48: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/runner.rb:66:in `block in run'
     47: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/builder.rb:116:in `call'
     46: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     45: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
     44: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     43: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/plugins/providers/virtualbox/action/check_accessible.rb:18:in `call'
     42: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     41: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/plugins/providers/virtualbox/action/clean_machine_folder.rb:17:in `call'
     40: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     39: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/plugins/providers/virtualbox/action/set_name.rb:19:in `call'
     38: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     37: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/plugins/providers/virtualbox/action/clear_forwarded_ports.rb:15:in `call'
     36: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     35: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/builtin/provision.rb:80:in `call'
     34: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     33: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/builtin/env_set.rb:19:in `call'
     32: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     31: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/plugins/providers/virtualbox/action/prepare_forwarded_port_collision_params.rb:30:in `call'
     30: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     29: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:49:in `call'
     28: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     27: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/plugins/providers/virtualbox/action/prepare_nfs_valid_ids.rb:12:in `call'
     26: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     25: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/plugins/synced_folders/nfs/action_cleanup.rb:25:in `call'
     24: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     23: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/builtin/synced_folder_cleanup.rb:28:in `call'
     22: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     21: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/builtin/synced_folders.rb:87:in `call'
     20: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     19: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/plugins/providers/virtualbox/action/prepare_nfs_settings.rb:19:in `call'
     18: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     17: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/plugins/providers/virtualbox/action/clear_network_interfaces.rb:26:in `call'
     16: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     15: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/plugins/providers/virtualbox/action/network.rb:123:in `call'
     14: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     13: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/plugins/providers/virtualbox/action/network_fix_ipv6.rb:41:in `call'
     12: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
     11: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/plugins/providers/virtualbox/action/forward_ports.rb:31:in `call'
     10: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
      9: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/builtin/set_hostname.rb:16:in `call'
      8: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
      7: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/plugins/providers/virtualbox/action/sane_defaults.rb:38:in `call'
      6: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
      5: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/plugins/providers/virtualbox/action/customize.rb:40:in `call'
      4: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/action/warden.rb:34:in `call'
      3: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/plugins/providers/virtualbox/action/boot.rb:16:in `call'
      2: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/plugins/providers/virtualbox/driver/version_5_0.rb:704:in `start'
      1: from /usr/share/rubygems-integration/all/gems/vagrant-2.0.2/lib/vagrant/util/retryable.rb:17:in `retryable'
/usr/share/rubygems-integration/all/gems/vagrant-2.0.2/plugins/providers/virtualbox/driver/version_5_0.rb:714:in `block in start': There was an error while executing `VBoxManage`, a CLI used by Vagrant (Vagrant::Errors::VBoxManageError)
for controlling VirtualBox. The command and stderr is shown below.

Command: ["startvm", "86110386-1535-4bdd-ae81-eb1ea135df4f", "--type", "gui"]

Stderr: VBoxManage: error: Could not launch a process for the machine 'chocolatey-test-environment_default_1577465763383_49268' (VERR_FILE_NOT_FOUND)
VBoxManage: error: Details: code VBOX_E_IPRT_ERROR (0x80bb0005), component MachineWrap, interface IMachine, callee nsISupports
VBoxManage: error: Context: "LaunchVMProcess(a->session, sessionType.raw(), Bstr(strEnv).raw(), progress.asOutParam())" at line 600 of file VBoxManageMisc.cpp
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["startvm", "86110386-1535-4bdd-ae81-eb1ea135df4f", "--type", "gui"]

Stderr: VBoxManage: error: Could not launch a process for the machine 'chocolatey-test-environment_default_1577465763383_49268' (VERR_FILE_NOT_FOUND)
VBoxManage: error: Details: code VBOX_E_IPRT_ERROR (0x80bb0005), component MachineWrap, interface IMachine, callee nsISupports
VBoxManage: error: Context: "LaunchVMProcess(a->session, sessionType.raw(), Bstr(strEnv).raw(), progress.asOutParam())" at line 600 of file VBoxManageMisc.cpp

[Mistuke]

@yaxu Fastest way to get an answer on that is to just ask them at https://gitter.im/chocolatey/choco they're usually quite fast with responding when it's not holidays :)

[yaxu]

After a few attempts I finally managed to get the test environment running on my laptop. My guess is that the problem is that atom isn't installing. Indeed this is known and it has an test exemption: https://chocolatey.org/packages/Atom/1.50.0#testingResults

[yaxu]

We could switch to vscode.. But I think better to resubmit as-is (with updated tidal version) and ask for an exemption.

[yaxu]

Resubmitted for now: https://chocolatey.org/packages/TidalCycles/1.6.1

[yaxu]

I think the right thing to do would be to split this out into several packages.. tidalcycles-lib (for the haskell library), superdirt, tidalcycles-atom (for the atom plugin) and tidalcycles-vscode (for the code plugin).. then we'd only have to mark the atom plugin one as exempt from testing. This wouldn't be too much work..

Here's my guess at a vscode version https://github.com/tidalcycles/tidal-chocolatey/blob/vscode/tidal/tools/chocolateyinstall.ps1