Kristoffer Carlsson

> am i correct in understanding that the way subprojects work is that it makes sure parent/siblings/nephew/etc packages in the mono-repo are always what is resolved to Every project in...

- [ ] Should write packages in workspace to manifest - [ ] Also write extensions for package to manifest

``` (test) pkg> dev .. Resolving package versions... No Changes to `~/JuliaPkgs/Pkg.jl/test/Project.toml` Updating `~/JuliaPkgs/Pkg.jl/Manifest.toml` [0dad84c5] + ArgTools v1.1.2 [56f22d72] + Artifacts v1.11.0 [f43a241f] + Downloads v1.6.0 [7b1f6079] + FileWatching v1.11.0...

``` (MonoRepo/PrivatePackage/test) pkg> st Status `~/MonoRepo/PrivatePackage/test/Project.toml` [a23bb17a] PrivatePackage v0.1.0 `PrivatePackage` # this is now relative to manifest [8dfed614] Test v1.11.0 ``` should print paths relative to project when doing a...

I'm seeing some (I think) spurious warnings like: ``` Warning The project dependencies or compat requirements have changed since the manifest was last resolved. It is recommended to `Pkg.resolve()` or...

> If that is true, couldn't it lead to confusing downgrades of packages due to test dependencies? I don't know if they are confusing or not. But being able to...

> I fully agree that having julia --project=test/ runtests.jl "just work" would be amazing. I am just a little bit surprised that the "parent project" would have to know about...

> How does this work with using different julia versions? Well, as will all Pkg apps they are more or less locked to a specific julia version (the one you...

With https://github.com/JuliaLang/Pkg.jl/pull/4495 we can resolve for other julia versions natively.

> which would make the julia version easy and explicit? You don't want the julia version explicit, you want to use the one that is in the manifest. So if...