Skip to content
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

Replace term with anstream? #856

Open
Pat-Lafon opened this issue Nov 17, 2023 · 7 comments
Open

Replace term with anstream? #856

Pat-Lafon opened this issue Nov 17, 2023 · 7 comments

Comments

@Pat-Lafon
Copy link
Contributor

Pat-Lafon commented Nov 17, 2023

Not a high priority but I noticed that a more up-to-date Cargo.lock brings in a second version of bitflags because of the dependency on term. This got me looking into this crate which generally doesn't seem to be well maintained(Stebalien/term#93) and has since been replaced in the ecosystem afaik(Termcolor was the original replacement, but maybe people are moving away from that for anstream rust-lang/cargo#12751).

It would probably benefit Lalrpop to refactor the cli to use anstream instead of term and it might even clean up that area of the code base a little bit with it's hacks like FakeTerminal

@dburgener
Copy link
Contributor

I started briefly poking at this. Part of the challenge here is that our usage of term is also tied into our ASCII canvas dependency (https://github.com/nikomatsakis/ascii-canvas). Ascii canvas is also written by Niko like lalrpop, and it looks like it was originally part of lalrpop, but since it had independent use, he spun it out into its own separate crate. The term dependency is used across the API between lalrpop and ASCII canvas. Probably the strategy here needs to be to first go update ASCII canvas (I imagine we can ping Niko and get that change in even though he's presumably not actively managing the project). Then that could get released as a breaking change, since the API would move away from term. Then we can make a change here to update our ASCII canvas version while also dropping the term dependency.

I might work on this at some point, but it seems like a pretty large task, so I'm not able to commit the time right now.

@nikomatsakis
Copy link
Collaborator

nikomatsakis commented May 21, 2024 via email

@Pat-Lafon
Copy link
Contributor Author

I started briefly poking at this. Part of the challenge here is that our usage of term is also tied into our ASCII canvas dependency (https://github.com/nikomatsakis/ascii-canvas). Ascii canvas is also written by Niko like lalrpop, and it looks like it was originally part of lalrpop, but since it had independent use, he spun it out into its own separate crate. The term dependency is used across the API between lalrpop and ASCII canvas. Probably the strategy here needs to be to first go update ASCII canvas (I imagine we can ping Niko and get that change in even though he's presumably not actively managing the project). Then that could get released as a breaking change, since the API would move away from term. Then we can make a change here to update our ASCII canvas version while also dropping the term dependency.

I might work on this at some point, but it seems like a pretty large task, so I'm not able to commit the time right now.

Maybe not too bad? I threw together an "it-compiles" version over the last one/two hours(https://github.com/Pat-Lafon/lalrpop/tree/anstream)... though most of that was figuring out how the functionality was split over a couple of crates. Unfortunately I don't think colors are that easy to test(atleast neither of the crates seem to check for this)? It's probably a long tail of checking for differences in implementation.

@dburgener
Copy link
Contributor

Unfortunately I don't think colors are that easy to test(atleast neither of the crates seem to check for this)? It's probably a long tail of checking for differences in implementation.

Can you elaborate about what is concerning you there? I agree that it's challenging to test for changes in terminal coloring, particularly in terms of corner cases, cross platform support, different environments etc. But most of the color bugs aren't really all that bad. Even if we entirely lose color in some situation, or worse add color markers in an area where they won't be interpreted, that's not a show-stopper sort of bug.

My inclination would be to do as much manual testing as we reasonably can, and figure that if we missed something it won't be all that huge a problem for users, and we should be able to fix it pretty easily in a point release. Particularly if we were to get this in the for the next release which is breaking, then users would be manually upgrading anyways, and have an opportunity to see if things break during that, rather than have them break on a point release if we mess something up.

In terms of ascii-canvas users, crates.io has the handy reverse dependencies search, and it shows that lalrpop is the only user: https://crates.io/crates/ascii-canvas/reverse_dependencies

I would definitely advocate for pulling ascii-canvas into the lalrpop org. Github's org migration features are really good, and maintain previous links as a redirect, so doing org migrations tends to be pretty seamless for users, as long as you use the official github interface rather than just push a new copy or something.

@youknowone
Copy link
Contributor

If making test cases is possible, cargo insta is useful to make snapshot tests
https://crates.io/crates/cargo-insta

@nikomatsakis
Copy link
Collaborator

nikomatsakis commented May 24, 2024 via email

@dburgener
Copy link
Contributor

Thanks!

@Pat-Lafon do you want to create PRs for your code above? I'm happy to review and test.

I'd like it if we could do a release in the somewhat near future to get out the recent bug fixes (particularly #898, but also #896), but my preference would be if this could also get included.

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

No branches or pull requests

4 participants