Takafumi Arakaki

I don't think PkgEval is relevant here. Many uses of PkgEval are bandaids for the lack of specification, i.e., nonstrict enforcement of semver, in Julia. People write code without releasing...

> PkgEval is definitely relevant because it is part of that fuzzy status quo that has helped establish the current norms. Yes, I agree that PkgEval is relevant in understanding...

> The problem is that, with time, it is very likely that the version of dependencies in the docs Manifest.toml drift away from the version of dependencies in the main...

> There should be one Manifest In addition to the concern @goretkin raised, I'd like to mention that this makes it difficult for package authors to reliably test the package...

> > I'd like to mention that this makes it difficult for package authors to reliably test the package with different sets of dependencies (e.g., additionally testing against the oldest...

The issue in the OP seems to be already addressed by https://github.com/JuliaLang/julia/pull/28446. But is it still an option to add a different accessor as suggested by @StefanKarpinski https://github.com/JuliaLang/LinearAlgebra.jl/issues/513 and perhaps...

How about using `Meta.parse`? ```julia code = """ julia> for i in 1:1 @show i end i = 1 """ expr, i = Meta.parse(code, length("julia> ")) output = code[i:end] @assert...

I guess you need to combine `Meta.parse` with the whitespace-based heuristic to treat multiple expressions like ```julia julia> println(1) println(2) 1 2 ```