Drop once_cell / new MSRV Policy

[mitsuhiko]

It looks like once_cell now moved this crate up to 1.56. That's significantly above where it was before (1.40). This crate either has to move up, or a replacement for once_cell has to be found.

I am going to watch this for a few days now and see then what to do.

Refs matklad/once_cell#201

[alexheretic]

tbh I was disappointed to see lazy_static reappear in my dependency tree with 0.15.2. Can't old compiler users just use old lockfiles?

[mitsuhiko]

@alexheretic so the reason I ended up deciding to use lazy_static again is also partially because I think with the recent changes to once_cell, lazy_static is the more lightweight solution. It compiles faster, is generally more lightweight and until the cell lands in std it's likely that projects end up having both dependencies anyways. It felt at least like it's a better choice than to vendor another type in this crate and others.

I'm generally not sure right now what a good longer term strategy is. Generally speaking though I think this will eventually resolve when the community as a hole knows what the MSRV policy the ecosystem wants. I'm a bit between chairs right now.

[alexheretic]

Thanks for the reply. I guess it was just that a lot of my projects had managed to get away from lazy_static and I thought the ecosystem was moving that way too. With msrv I dislike how it impacts users who are on a recent/the latest compiler, like here where I'm pinning 0.15.1. I'd have thought it should be people using outdated rustc that should be pinning stuff (if anyone has to). Though now you've explained you had other reasons, more than just msrv, this is all perhaps irrelevant.

[eminence]

Hi all, the terminal_size upgrade in #139 would bump the MSRV from 1.40.0 (2019-12-19) to 1.48.0 (2020-11-19).

I see that once_cell is dropped, so I'm wondering if you would consider a MSRV bump to 1.48 in order to upgrade terminal_size

[mitsuhiko]

Moving up to 1.48 is fine for sure.

[messense]

Moving up to 1.48 is fine for sure.

Opened #146

[Shatur]

Because of outdated version of encode_unicode due to MSRV I have multiple versions of it in my dependency tree.

[russellbanks]

It compiles faster, is generally more lightweight and until the cell lands in std it's likely that projects end up having both dependencies anyways.

Could this be revisited? OnceCell has been partially stabilised into std and the lazy_static ReadMe now has a section on how to achieve the same thing with OnceLock.

[mitsuhiko]

@russellbanks what is the ask here in particular? To remove the lazy-static dependency?