Default config effectively wipes downloaded binaries on every Start

[logan]

The first call to Start takes a long time, because it has to download and extract binaries. The second call to Start should be faster, because it can skip the download and extraction. However, in practice, unless you set BinariesPath on the config, Start downloads and extracts every time.

The reason why is here:

	if ep.config.runtimePath == "" {
		ep.config.runtimePath = filepath.Join(filepath.Dir(cacheLocation), "extracted")
	}

	if ep.config.dataPath == "" {
		ep.config.dataPath = filepath.Join(ep.config.runtimePath, "data")
	}

	if err := os.RemoveAll(ep.config.runtimePath); err != nil {
		return fmt.Errorf("unable to clean up runtime directory %s with error: %s", ep.config.runtimePath, err)
	}

	if ep.config.binariesPath == "" {
		ep.config.binariesPath = ep.config.runtimePath
	}

In the default config, all paths are "". So, we end up putting downloaded-and-extracted binaries under the runtime path. But, first, we delete everything under the runtime path.

This is probably a duplicate of #141.

I recommend a different default location for binaries.

[fergusstrange]

This is intended behaviour. We clear down the entire test (runtime) path and re-extract the binaries every time. We do (or should) avoid redownloading them however using the caches archive location.

I'm open to rethinking this approach as the configuration has got quite bloated and confusing, but that will likely require some non backwards compatible changes which will in turn produce it's own issues. Let me know thoughts?

[andriygm]

@fergusstrange the default configuration seemed to still take a while (7-8 seconds for me) even on subsequent runs even with the default caching behavior. I had to explicitly set the binaries path to BinariesPath(homeDir + "/.embedded-postgres-go/binaries") so they wouldn't clear out:

postgres := embeddedpostgres.NewDatabase(embeddedpostgres.DefaultConfig().
	Version(embeddedpostgres.V17).
	BinariesPath(homeDir + "/.embedded-postgres-go/binaries").
	Port(5433))

I'm not sure that it makes sense to clear the binaries out after every run, especially given how the package may be used across multiple tests -- would a reasonable compromise be to set the default configuration to use a separate binaries path than the data/runtime path?