Skip to content

move to std once_cell #251

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Conversation

2ndDerivative
Copy link

This would bump the MSRV to 1.80.0 to remove the once_cell dependency.

As of 1.80, the lazy mechanism here can be replaced by an actual std LazyLock

@epage
Copy link
Collaborator

epage commented May 22, 2025

I've merged #253 instead which allows us to maintain our MSRV

@epage epage closed this May 22, 2025
@2ndDerivative
Copy link
Author

The point of this was not to just get once_cell out of direct dependencies, but to reduce the dependency graph. This doesn't do anything along those lines, but oh well. Could've just not merged this and delayed until the next MSRV bump

@hanna-kruppe
Copy link
Contributor

I think that’s the intent with the *_polyfill crates, lower versions wrap a third party crate and higher versions instead wrap the corresponding standard library APIs, so dependents by default get the std re-export that’s very cheap to compile and has no further dependencies (see is_terminal_polyfill for example). But it seems that once_cell_polyfill v1.70.0 doesn’t do that, maybe there’s been a mixup in the process of preparing that release?

@2ndDerivative
Copy link
Author

It hasn't done that for 1.56 either, yeah. Thought someone was messing with me there xD

@epage
Copy link
Collaborator

epage commented May 22, 2025

... I made the change to main-v1.70 to remove once_cell. No idea how that got lost. 1.70.1 is now out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants