Writing tests in VS Code: workflow, autocomplete, and tooltips

General Usage
, ,
8

I interpreted this section of the manual to mean “easier than using add”…? I was imagining the following scenario:

  • I’m working on some project (i.e. not a package) with one or more dependencies that I’d like to edit.
  • I can dev those packages in the context of that project’s environment.
  • If I used dev --local Moo (*), then these packages would appear under the same directory of the project… so I’d end up with:
some_project_dir/
    Moo/
        src/
        test/
        ...
        Project.toml
    Project.toml

but then always have some_project_dir as the active environment? (I was under the impression that most people avoided using the global environment so as to ensure isolation between activities, which is how I’d work in e.g. Python too.)

If I’m just working on Moo, then naively this doesn’t seem simpler/easier, but maybe I’m missing something? … maybe there is a rule of thumb that one’s active environment should always be a non-package environment, rather than a package environment, and there are other reasons that this is preferable/cleaner? But then I’m not convinced by that, as if I need to add a dependency to the package then I would need to be in the context of the package env :slight_smile:

Also, apologies for the extensive questions – I have spent an embarrassingly long time scouring the internet off-and-on over the last days/weeks trying to understand how the package & module system works, and find a consensus on various workflow-related matters!

(*) Or refer to an explicit check-out of the package. For sanity when using VSCode I would have thought one would want to retain the packages one is editing in the context of a particular project under that project’s directory(?)