This is a pretty minor thing, but I figured I’d ask about it anyway.
In VS Code, when working on code in a package, I can command-click on a function call and be taken to its definition (although if there are multiple methods with the same name, it can’t figure out which one is being called, but in practice it works decently well).
However, if I’m working on that package’s unit tests, navigation to a package function is unavailable, so I generally need to go use the text search to locate methods. Is there some way to get this navigation working in this common use case?
Interesting! I do already have a Project.toml in my tests folder, but I think I’ll use option 2, because that seems like it will “just work” for new developers, but option 1 would need them all to dev the project individually (unless I check in the Manifest.toml, which I think I don’t want to do), right?
in test/Project.toml, where PackageName is the name of your package. This works in Julia >= 1.11, which is probably what new developers would be using.
Oh indeed, that seems to be working - “delete the Manifest.toml” isn’t normally in my repertoire, I think I was trying to use resolve and/or instantiate within the REPL, I don’t remember exactly how, but clearly it wasn’t working.
Yes, it is somewhat annoying that sometimes you have to delete the manifest file manually, and that Julia (or Pkg?) cannot figure out that this might be needed itself. At least Julia or Pkg should give a hint in such a situation that this might be needed.
Just to be clear: I don’t think (committed) Manifests have any place in package development. Manifests are for when you need exactly reproducible environments, like for a research project. I would recommend setting up make clean (if you’re on Unix) to remove all Manifest.toml files in your project.
Yes, the [sources] feature has a large variety of options, including a GitHub repo address. Of course, you should not be using that for the package to be tested in the Project.toml describing the test environment. You want to test the version of the code currently on your hard drive, not whatever currently is on GitHub.
Thanks a lot for the answer.
But then, if I understand correctly, you cannot really use this approach in a published package for running the tests on this package?
I don’t understand what you mean… what approach? What doesn’t work?
My recommendation for testing, independent of whether this fixes issues with VS Code (which I don’t use), is
Use a test/Project.toml, as of recently with [sources] pointing to the parent folder, instead of the old [extras] approach. That makes the docs and the test environments behave equivalently, avoids the undocumented “magic” of the tests [targets] and makes the TestEnv package mostly unnecessary.
Do not commit any Manifest.toml files
If you need to start a REPL to run tests using a pre-1.11 version of Julia, ] dev .. should do the trick (Personally, I set up make devrepl to do that). Of course, ] test and TestEnv still also work, both with [sources] and with test/Project.toml.
Yeah, I agree with that - I highly prefer to develop things as well-behaved packages, and set all relevant constraints (hopefully loosely) in the Project.toml.
The other big use case for us is application deployment environments, where we need to upgrade dependencies and versions carefully from one deployment to the next.