Drop TimeZones.jl dependendency

[oxinabox]

TimeZones v1.6 chagned the representaion of FixedTimeZone (big improvement on GC).
This upgrade means can't load the old Checkpoints without loading the right version of TimeZones.jl.
Which normally we could do via Pkg.activate(jlsofile), before we do using TimeZones and JLSO.load(jlsofile)
But Pkg.activate has no effect due to the fact that a newer version of TimeZones.jl has already been loaded when JLSO.jl was loaded.

TimeZones.jl, unlike our other deps, contains a basic data type that is commonly used for data we want to store.

JLSO has a indirect dependency on it via Memento.
It should be reasonable enough to drop Memento and just use the stdlib logger.
We only log in a a few places:

JLSO.jl/src/serialization.jl

Line 56 in 04b83b3

warn(LOGGER, e)

JLSO.jl/src/upgrade.jl

Line 25 in 04b83b3

info(LOGGER, "Upgrading $src -> $dest")

[oxinabox]

@rofinn why the 👎 ?

[rofinn]

Cause only logging in a few places isn't a reason to switch logging backends. The primary benefit of Memento is the flexible configuration system which is still applicable here. For example, consider loading hundreds of JLSO files which need to be upgraded as part of some analysis. If you find that output overly verbose you can easily disable it along with our other libraries when configuring Memento. AFAIK, that's less easy with the base logging and would be a completely different process in most of our script.

Honestly, I think the issue is with how Julia's environment system works. There are numerous issues/bugs with the current Pkg.activate, package loading and serialized Julia objects. For example, Pkg.activate has very weird behaviour if you already have some packages loaded, which isn't JLSO specific. This isn't going to be easily resolved by simply changing a JLSO dependency, that's just side-stepping the main issue here. FWIW, I think we should look into deserializing Julia objects on a worker process with the correct environment (e.g., addprocs(exeflags="--project"), remotecall(f, ...)). That would largely resolve the issue of having different package versions loaded so long as the communication between the manager and worker doesn't depend on it.

[oxinabox]

This isn't going to be easily resolved by simply changing a JLSO dependency, that's just side-stepping the main issue here.

While this is true, TimeZones.jl is the only upstream dependency of JLSO that defines an object type that is likely to be serialized in a JLSO.
So side-stepping it here seems like it would give us a lot of benefit, with very little effort.

In contrast to worker processes (which I agree is a good idea) which is much more effort.

[rofinn]

Memento doesn't explicitly depend on TimeZones.jl anymore.

[iamed2]

We don't depend on the version of Memento that dropped TimeZones.jl though, and TimeZones.jl is still in the Project.toml

[rofinn]

Hmm, good point. We should bump the Memento version. We just have a compat entry for TimeZones as a test dependency which is unrelated to Memento (we use timezones in our test files and the ZonedDateTime struct format changed). I don't remember, what's the best practice is for test dependency compat entries?

[iamed2]

I don't remember, what's the best practice is for test dependency compat entries?

I'm not sure. I don't know if the behaviour of Pkg.test is documented either.

[oxinabox]

For test dependencies, their compat goes in [compat] (like for main dependencies) and they get listed in [extras] and [target] test.
We do this a lot, in many packages.
Though we are not as strict about always including the compat entry for test dependencies, we really should be.