# Svn was not found in your PATH, skipping source download

**URL:** https://discourse.roots.io/t/svn-was-not-found-in-your-path-skipping-source-download/22958
**Category:** trellis
**Tags:** bedrock
**Created:** 2022-04-24T01:20:52Z
**Posts:** 5

## Post 1 by @mZoo — 2022-04-24T01:20:52Z

Using Trellis `v1.14.0`, I’m getting following error (suddenly, perhaps after adding some `site`, `wpackagist` plugins) on deploy to _staging_ but not to _production_ server.

```
Now trying to download from source", " Failed to download wpackagist-plugin/ultimate-addons-for-gutenberg from dist: \
curl error 28 while downloading https://downloads.wordpress.org/plugin/ultimate-addons-for-gutenberg.1.25.4.zip: \
Connection timed out after 10004 milliseconds", " \
Now trying to download from source", "", \
"In SvnDownloader.php line 39:", "", \
"svn was not found in your PATH, skipping source download ", "
```

I checked and `svn` isn’t available (to admin or web user) on production either, via command line.

Seems similar to [this thread](https://discourse.roots.io/t/composer-wp-packagist-failure-to-download-on-trellis-deploy/6018/16) and I ran `trellis provision --tags php staging` again, but same result.

The exception comes from:

```
protected function doDownload(PackageInterface $package, $path, $url, PackageInterface $prevPackage = null)
    {
        SvnUtil::cleanEnv();
        $util = new SvnUtil($url, $this->io, $this->config, $this->process);
        if (null === $util->binaryVersion()) {
            throw new \RuntimeException('svn was not found in your PATH, skipping source download');
        }

        return \React\Promise\resolve();
    }
```

I’m pretty sure that `apt install subversion` isn’t the Trellis solution, even if it would work.

Any suggestions?

---

## Post 2 by @mZoo — 2022-04-24T01:25:40Z

Incidentally, I’m not sure where exactly the file that this code resides in _is_.

Running `which composer` leads me, locally, to `/usr/local/Cellar/composer`.

While `grep -ri "doDownload(PackageInterface" /usr/local/Cellar` returns:

```
Binary file /usr/local/Cellar/wp-cli/2.6.0/bin/wp matches
Binary file /usr/local/Cellar/composer/2.3.4/bin/composer matches
```

(Note `trellis provision --tags wp-cli staging` also not a solution.)

---

## Post 3 by @swalkinshaw — 2022-04-24T03:48:22Z

The SVN part isn’t the actual issue; it’s just a fallback method to download from source because the normal “dist” method timed out:

```
Failed to download wpackagist-plugin/ultimate-addons-for-gutenberg from dist: \
curl error 28 while downloading https://downloads.wordpress.org/plugin/ultimate-addons-for-gutenberg.1.25.4.zip: \
```

So there’s some connectivity/networking issue on your server where that URL times out. Hard to say what the problem could be, but I’d suggest debugging that using curl’s verbose mode to see what’s going on.

---

## Post 4 by @mZoo — 2022-04-24T15:13:34Z

Thanks, Scott.

```
curl https://downloads.wordpress.org/plugin/ultimate-addons-for-gutenberg.1.25.4.zip -vvv
* Trying 198.143.164.250:443...
* TCP_NODELAY set
* connect to 198.143.164.250 port 443 failed: Connection timed out
* Failed to connect to downloads.wordpress.org port 443: Connection timed out
* Closing connection 0
curl: (28) Failed to connect to downloads.wordpress.org port 443: Connection timed out
```

Same with `--no-tcp-nodelay` flag (minus that step).

Tried `wget` which also fails on [wordpress.org](http://wordpress.org) but not on other sites (google,com).

I’m thinking maybe one of the steps from this [SO post](https://superuser.com/a/1064245/328722):

1. Verify name servers are correct within /etc/resolv.conf

```
nameserver 127.0.0.53
options edns0 trust-ad
```

Matches production, so assuming correct.

1. If #1 resolv settings are are correct for primary and secondary nameservers, verify that 192.168.10.10 has the ability to resolve hosts. (simple nslookup to [google.com](http://google.com) is a good test for this, if timeout occurs then then this could be part of the issue)

```
Server: 127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	google.com
Address: 142.250.188.14
Name:	google.com
Address: 2607:f8b0:4005:806::200e
```

And

```
nslookup wordpress.org
Server: 127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	wordpress.org
Address: 198.143.164.252
```

1. Ensure that your nginx server has the ability to query name servers externally or internally via firewall (port 53 tcp/udp)

Not sure how to do that. It’s a brand new DO droplet.

1. Look for potential resolver settings within nginx configuration options and or set resolution timeout setting where applicable and restart nginx.

Again, at a loss. Re-ran the nginx provisioning tag.

1. If its still an issue attempt to add the host of the incoming request connection within /etc/hosts on 192.168.10.10.

Do they mean this:

```
198.143.164.250 downloads.wordpress.org
```

And if so, would I do that within Trellis?

---

## Post 5 by @swalkinshaw — 2022-04-24T18:19:51Z

> [@mZoo](#):
>
> Do they mean this:
> 
> ```
> 198.143.164.250 downloads.wordpress.org
> ```
> 
> And if so, would I do that within Trellis?

Probably, but `/etc/hosts` just fixes DNS resolution issues. From your curl example, the host is already resolving to that IP:

```
curl https://downloads.wordpress.org/plugin/ultimate-addons-for-gutenberg.1.25.4.zip -vvv
* Trying 198.143.164.250:443...
```

So adding `198.143.164.250 downloads.wordpress.org` to your hosts file just seems redundant, but I suppose it’s worth a try :man_shrugging:

I’d ignore doing things the “trellis way” for now and just manually modify `/etc/hosts` to see if it helps.

I’m not sure how much more help I can offer beyond this, but if possible I’d just re-create a new staging server and see if that fixes it.