Are there certain dependencies that can be removed? about moka HOT 10 CLOSED

Closing this issue as the next branch was merged into the master branch.

I will run some pre-release testing, and if everything goes well, I will publish Moka v0.9.0 to crates.io.

from moka.

Hi. Thank you for the offer. Well, all these dependencies are in-use, of course. However if you only use moka::dash::Cache in serenity, you could remove the following dependencies from moka:

• crossbeam-epoch
• uuid
• thiserror (but serenity already depends on it)

To do that, you will need the followings:

1. Add a crate feature called sync to Cargo.toml, and add it to the default features.
2. In Cargo.toml, make the following dependencies optional, and enable them only when sync or future feature is specified:
   • crossbeam-epoch
   • uuid
   • thiserror
3. Make the following modules enabled only when sync feature is specified: (Use #[cfg(feature="sync")])
   • sync::builder
   • sync::cache
   • sync::segments
   • sync::value_initializer
4. Make the following modules enabled only when sync or future feature is specified: (Use #[cfg(any(feature="sync", feature="future"))])
   • sync
   • cht
   • common::error

(I have not tried above by myself. So there may be additional changes required)

Once done, and a new version of moka is published to crate.io, you will update moka dependency in serenity to the followings:

serenity's Cargo.toml

[dependencies.moka]
version = "0.9"
default-features = false
features = ["dash", "atomic64", "quanta"]
optional = true

Also I found that scheduled-thread-pool v0.2.5 uses an older version of parking_lot (v0.11.2). serenity already depends on parking_lot but a newer version (v0.12.0). I see the master branch of sfackler/scheduled-thread-pool has it already upgraded to v0.12 via sfackler/scheduled-thread-pool#15, but no new version of scheduled-thread-pool has been published to crates.io.

So could you please open a GitHub issue to sfackler/scheduled-thread-pool and ask them to publish a new version to crates.io?

Thanks!

from moka.

Yeah. I will take it over as I will need to move some modules around. I merged #141 into a new topic branch gh141-optout-sync.

from moka.

OK. I have created two PRs:

1. #142
2. #143

I already merged #142, which was for moving some modules around.

#143 is for the sync feature and contains your commits and my commits. Once merged, disabling the sync feature (as well as future feature) will remove the following dependencies from moka:

• crossbeam-epoch
• uuid
• thiserror

I will come back in a couple of hours to review the PR and will merge it into the next branch. This branch is for moka v0.9.0 release, while the master branch is for v0.8.x releases. I will merge #143 into next branch because it contains some breaking changes.

Please give me a couple of weeks to develop other stuff for v0.9.0 milestone.

from moka.

I reviewed and merged PR #143 into the next branch. I will keep this issue open until the PR gets merged into the master branch.

from moka.

@Milo123459 — I have published Moka v0.9.0 to crates.io 🎉

from moka.

#141 made the pr!

from moka.

Thanks for making the PR #141. Hmm, there are so many compile errors.

After a brief review, I noticed a couple of things:

1. moka::dash::Cache actually depends on the following crates, so we cannot remove them:
   • uuid
   • thiserror
2. moka::dash::Cache actually depends on some modules under moka::sync, so we cannot simply disable then even though no sync or future feature are specified:
   • I would better to do some refactoring: e.g. move these shared modules under a new super module.

Let me take over your stuff and finish it. I will merge #141 into a topic branch and do the rest of the work.

from moka.

Are you sure you want to take it over?

Either way, thank you!

from moka.

I am doing some experiments here in gh141-experiments branch. It is almost working. I will continue working tomorrow as it is midnight now in my timezone.

I found the following is not true:

• moka::dash::Cache actually depends on the following crates, so we cannot remove them:
  • uuid
  • thiserror

So I am able to remove uuid and thiserror crates when both sync and future features are not specified.

from moka.