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?

[triple-twenty]

I also spent some time figuring this out today. I wanted to speed up my test runs in the case where, for example, I'm iterating on a single test and re-running the same test frequently. I was seeing 18-20 second duration for each run, which felt unbearably slow.

At first I thought it was postgres, but it turns out most of the time was spent unpacking the binaries. Once I set the BinariesPath, it worked.

In hindsight, since the docs document a default value for BinariesPath of $USER_HOME/.embedded-postgres-go/extracted, I incorrectly assumed that changing that config to a different path would not change the behavior. So that feels too subtle, in my humble opinion – something more explicit like FullReset(bool) (or CleanBinaries(bool) might be more obvious.

I also think it's a peculiar default – wouldn't it be possible to extract the binaries into a version-specific path, so that there's no possible conflict? Given that this is intended for testing, it seems preferable to optimize the speed of the tests where possible.

Am I missing something about the potential for binaries to conflict?