# How to use VSCode and REPL to write and test a package?

**URL:** <https://discourse.julialang.org/t/how-to-use-vscode-and-repl-to-write-and-test-a-package/78818>\
**Category:** VS Code\
**Tags:** question, package\
**Created:** [March 31, 2022, 3:28pm UTC](https://discourse.julialang.org/t/how-to-use-vscode-and-repl-to-write-and-test-a-package/78818 "2022-03-31T15:28:31Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![lmiq](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lmiq/32/18314_2.png) [@lmiq](https://discourse.julialang.org/u/lmiq)\
**Post date:** [April 1, 2022, 1:44pm UTC](https://discourse.julialang.org/t/how-to-use-vscode-and-repl-to-write-and-test-a-package/78818/21 "2022-04-01T13:44:12Z")

</div>

Yes, that can happen. Though I don’t remember the last time I had these kind of problems if I keep Plots up to date. That is part of what I’m trying to convey, that although these issues can happen, I am not sure if they are frequent enough to justify much more environment management complications. But of course that will depend on the specific packages and dependencies each one is dealing with.

---

<div class="post-metadata">

**Author:** ![Nathan\_Boyer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nathan_boyer/32/14825_2.png) [@Nathan\_Boyer](https://discourse.julialang.org/u/Nathan_Boyer)\
**Post date:** [April 1, 2022, 2:09pm UTC](https://discourse.julialang.org/t/how-to-use-vscode-and-repl-to-write-and-test-a-package/78818/22 "2022-04-01T14:09:55Z")

</div>

> [@pdeffebach](#):
>
> I keep the following in my startup.jl

How would I possibly figure out to add that to my `startup.jl`?

> [@pdeffebach](#):
>
> But ultimately, OP, I don’t think it’s that complicated.

You are suggesting yet another entirely new workflow and external package from those already suggested, so yes it is complicated to know what to use.

- Is `main` defined in `runtests.jl`, `MyPackage.jl`, or `myfile.jl`?
- How is Infiltrator different from the built-in VSCode “Run and Debug”?
- I need to work more interactively than to test all my code at once. It usually takes me three tries to write one line correctly. Can you test line-by-line with this workflow?

---

<div class="post-metadata">

**Author:** ![Nathan\_Boyer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nathan_boyer/32/14825_2.png) [@Nathan\_Boyer](https://discourse.julialang.org/u/Nathan_Boyer)\
**Post date:** [April 1, 2022, 2:12pm UTC](https://discourse.julialang.org/t/how-to-use-vscode-and-repl-to-write-and-test-a-package/78818/23 "2022-04-01T14:12:42Z")

</div>

> [@jlperla](#):
>
> But for your immediate needs: if you use the TestEnv I promise you that your grief will end.

I will try this out today. Thanks.

---

<div class="post-metadata">

**Author:** ![jlperla](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlperla/32/34332_2.png) [@jlperla](https://discourse.julialang.org/u/jlperla)\
**Post date:** [April 1, 2022, 2:16pm UTC](https://discourse.julialang.org/t/how-to-use-vscode-and-repl-to-write-and-test-a-package/78818/24 "2022-04-01T14:16:48Z")

</div>

> [@ianfiske](#):
>
> I usually advise to create an environment in the package’s `/examples` folder that has `dev .` to use the package and also has `Plots` or `Makie` added

Yes, this comes up in benchmarking as well. @davidanthoff I think this is another useful feature.

Basically, if someone wanted to activate an environment with subfolder other than test, then do the equivalent of `] activate subfolder` and then `] dev .` where `.` is the path to the main project file.

Sadly I don’t think it is enough for the test environment? @oxinabox any ideas on whether the `] dev .` after `] activate test` is enough in some cases? The code in [https://github.com/JuliaTesting/TestEnv.jl/blob/release-1.8/src/activate\_set.jl](https://github.com/JuliaTesting/TestEnv.jl/blob/release-1.8/src/activate_set.jl) does lots so I don’t have a mental picture of whether some of it is for corner cases.

---

<div class="post-metadata">

**Author:** ![jlperla](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlperla/32/34332_2.png) [@jlperla](https://discourse.julialang.org/u/jlperla)\
**Post date:** [April 1, 2022, 2:22pm UTC](https://discourse.julialang.org/t/how-to-use-vscode-and-repl-to-write-and-test-a-package/78818/25 "2022-04-01T14:22:47Z")

</div>

> [@ianfiske](#):
>
> In the past, I have seen version conflicts when I keep anything other than bare-bones (BenchmarkTools, Revise, Infiltrator, etc) in my main environment. The environment stacking solution seems nice in theory, but adding Plots to v1.7 adds a _lot_ to that environment’s Manifest

100% agree. I feel that the least-painful approach is to only keep packages in the main environment which should NEVER show up as direct dependencies, and don’t have too extreme of dependencies themselves. So mine is never more complicated than just doing the following with a new global environment.

`] add Revise TestEnv Infiltrator BenchmarkTools PkgBenchmark`

Everything else I keep in reproducible package/manifests - which never depend on those directly since they are development tools.

---

<div class="post-metadata">

**Author:** ![pdeffebach](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pdeffebach/32/10320_2.png) [@pdeffebach](https://discourse.julialang.org/u/pdeffebach)\
**Post date:** [April 1, 2022, 3:38pm UTC](https://discourse.julialang.org/t/how-to-use-vscode-and-repl-to-write-and-test-a-package/78818/26 "2022-04-01T15:38:34Z")

</div>

> [@Nathan\_Boyer](#):
>
> - Is `main` defined in `runtests.jl` , `MyPackage.jl` , or `myfile.jl` ?
> - How is Infiltrator different from the built-in VSCode “Run and Debug”?
> - I need to work more interactively than to test all my code at once. It usually takes me three tries to write one line correctly. Can you test line-by-line with this workflow?

- Define it in either `MyPackage.jl` or `myfile.jl`. I said in my post that it should be defined by the Package. i.e., the code that is run when you do `using MyPackage`.
- I don’t know. If you are comfortable with VS Code’s “Run and Debug” then use that.
- One option is to just have a `run_tests()` function defined in some script that’s being tracked and copy-and-paste code as needed into that function depending on what part you are working.

My point is that if you are asking for a “blessed” workflow, you are going to get tons of different answers. Julia is flexible, but with minimal knowledge of how workflows are in the abstract you can find something that works for you.

---

<div class="post-metadata">

**Author:** ![jlperla](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlperla/32/34332_2.png) [@jlperla](https://discourse.julialang.org/u/jlperla)\
**Post date:** [April 1, 2022, 6:20pm UTC](https://discourse.julialang.org/t/how-to-use-vscode-and-repl-to-write-and-test-a-package/78818/27 "2022-04-01T18:20:05Z")

</div>

> [@davidanthoff](#):
>
> Ah, that is a good point… One way out of that could be that we provide proper support for editing package `Project.toml` files with auto-complete etc, so that people stop using the package REPL to edit package `Project.toml` files…

Not sure. I think using the REPL for package operations is tough to bypass. Too many awesome features integrated deeply into Julia.

I feel like this may not be something that could be worked around with tooling entirely. Seems like the package manager really needs to implement a feature like TestEnv (e.g., `Pkg.activate_test("test")` or `Pkg.activate("test"; activate_as_test = true)` or whatever. Then package operations could still point at `test/Project.toml`, reset the manifest it uses, etc. I just don’t understand what is special about test projects (outside of doing a `] dev .` afterwards).

Dreaming of related features that address @ianfiske points, it would be great to have something which automatically does that last step for non-test project files. For example a `] activate benchmark --dev_parent` or `Pkg.activate("benchmark"; dev_parent = true)` does `] activate benchmark` then `]dev .` I would say that the `] dev .` even makes sense as the default behavior.

---

<div class="post-metadata">

**Author:** ![mefob](https://avatars.discourse-cdn.com/v4/letter/m/ea5d25/32.png) [@mefob](https://discourse.julialang.org/u/mefob)\
**Post date:** [April 2, 2022, 5:57pm UTC](https://discourse.julialang.org/t/how-to-use-vscode-and-repl-to-write-and-test-a-package/78818/28 "2022-04-02T17:57:05Z")

</div>

I feel this would be even more confusing, as it is a) specific to VS Code (not built-in to Julia) and b) doesn’t address the problem that @ianfiske mentioned below. Fundamentally, the only clean way I see has at least 3 different environments:

1. The main package environment “_main_”
2. The test environment “_test_”
3. At least one environment for actually using the package “_usage_”. Realistically we’ll need at least two environments, one internal to the package that an end-user will see on github and one for the developer that lives in a 2nd git repository.

The _main_ package environment should contain the bare minimum of dependencies that are needed to use the package, e.g. no _test_ dependencies and no interactive _usage_ dependencies. We don’t want these in the main package because they might cause conflicts with other dependencies a user of the package might have.

The _test_ environment should have everything that is needed to (unit) test the package, but nothing more. It should not have e.g. plotting dependencies if plotting is not part of the unit tests.

The _usage_ environment is an example of how the package is used. This is where all extra user-level dependencies are, e.g. plotting and data examples. These dependencies are not needed for unit testing, so they should not go to the _test_ environment, as they might stop an otherwise good test from completing.

There can be more than one _usage_ environment. For a registered package, it would be nice to have an example _usage_ environment that comes with the package. This _usage_ environment is complementary to the _test_ environment and geared towards documenting the behavior of the package. It might contain interactive notebooks that don’t make sense for unit tests, and we don’t want the tests to fail because of an issue with the interactive notebooks that an end user might never need.

On the other hand, a developer might not want to share all of the use cases of his package, they will probably also contain proprietary data. For example, if I develop a package to analyze data, I will do so using data that I cannot check into the repository of the package itself because it is a) to big or b) proprietary, but later I might add a couple internal examples to the package using sanitized data. An end user of myPackage then has 3 ways to use the package: 1. import 2. test 3. run the examples, probably in an interactive notebook.

I use the following workflow:

1. Create the myPackage with an integrated test environment
2. Create a 2nd project myPackage\_examples that uses Revise and the package above. All interactive exploring, testing etc. is done in this project.

I also find the overall situation very confusing. What I would wish for is:

1. Better documentation for the use-case that I described above [Workflow Tips · The Julia Language](https://docs.julialang.org/en/v1/manual/workflow-tips/) doesn’t work for me, and I am not even convinced that my approach is the way to go.
2. A community-agreed on workflow and some automation (i.e. **[  
PkgTemplates.jl](https://github.com/invenia/PkgTemplates.jl)** could automatically generate a 2nd project folder and repo myProject\_examples that uses Revise and myProject
3. From the VS Code side, it would be great if using the example project was transparent. If I am working on myPackage, I will have editor windows open for myPackage and myPackage\_examples, but the repl should run in myPackage\_examples.
4. A way to add internal examples with a separate environment to a package, similar to tests (maybe this is possible with nested environments, I haven’t tried).

Point 4. will help a user when trying out a new package.  
Let’s say I find greatPackage.jl on github and want to see how it works. In order not to contaminate my main environment, I need to first create a new project and add the package and all the dependencies that are needed to actually use the package. These are not dependencies of the package itself, but additional ones like plotting, so I have to do it manually. It would be much nicer if a package had an internal example folder with an example environment and a couple examples that could easily be cloned into a new project in my dev folder.

---

<div class="post-metadata">

**Author:** ![davidanthoff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/davidanthoff/32/223493_2.png) [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)\
**Post date:** [April 2, 2022, 6:12pm UTC](https://discourse.julialang.org/t/how-to-use-vscode-and-repl-to-write-and-test-a-package/78818/29 "2022-04-02T18:12:32Z")

</div>

Another idea could be to introduce a new `repl` target as a standard for packages (or maybe `example`?). So a `Project.toml` for a package might look like this:

```julia
name = "MyPackage"
uuid = "4e02106f-b1d8-42ee-a8ca-a30ff59aa51b"
version = "1.0.0"

[deps]
Tokenize = "0796e94c-ce3b-5d07-9a54-7f471281c624"

[compat]
Tokenize = "0.5.18"
julia = "1"

[extras]
Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40"
DataFrames = "a93c6f00-e57d-5684-b7b6-d8193f3e46c0"

[targets]
test = ["Test"]
repl = ["DataFrames"]

```

So now, when you open a folder with a file like that in the root in VS Code, and you open a REPL, we could activate a “virtual” project that has `MyPackage` deved, and then `DataFrames` is in there too, but not `Test`.

One can kind of emulate some of these things today by for exampling creating a project in an `example` folder, then deving the relative `./..` path into that project, and then adding whatever else one wants. The Problem with that approach for the VS Code extension is that this is now just some random project in a sub folder, and so we don’t really have any signal that we should auto-activate that project when we start a REPL…

---

<div class="post-metadata">

**Author:** ![lmiq](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lmiq/32/18314_2.png) [@lmiq](https://discourse.julialang.org/u/lmiq)\
**Post date:** [April 2, 2022, 7:35pm UTC](https://discourse.julialang.org/t/how-to-use-vscode-and-repl-to-write-and-test-a-package/78818/30 "2022-04-02T19:35:15Z")

</div>

I general, the big issue Is that all new users, and not so new, will always add packages to Main by default. IMHO how Main actually works is what is the problem.

Maybe Julia should always start in a new temporary type of environment that responds to “using” by adding the latest package version locally available.

If the user activated manually any other environment, the current behavior is fine.

I know from other discussions that this is not simple, but the truth is that I don’t know of any package that suggests the user to deal with environments in any way before installing. Thus bloating the Main is and will be the natural workflow.

---

<div class="post-metadata">

**Author:** ![davidanthoff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/davidanthoff/32/223493_2.png) [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)\
**Post date:** [April 2, 2022, 7:58pm UTC](https://discourse.julialang.org/t/how-to-use-vscode-and-repl-to-write-and-test-a-package/78818/31 "2022-04-02T19:58:00Z")

</div>

> [@lmiq](#):
>
> will always add packages to Main

What do you mean by `Main`? The global default v1.7 project? The package project when you activate it? The term “main” is not usually used for any of these 🙂

---

<div class="post-metadata">

**Author:** ![lmiq](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lmiq/32/18314_2.png) [@lmiq](https://discourse.julialang.org/u/lmiq)\
**Post date:** [April 2, 2022, 8:09pm UTC](https://discourse.julialang.org/t/how-to-use-vscode-and-repl-to-write-and-test-a-package/78818/32 "2022-04-02T20:09:04Z")

</div>

> [@davidanthoff](#):
>
> The global default v1.7 project?

I guess that one (although I don’t know of it being particular to 1.7 in any sense, so maybe that’s not it).

I mean the environment that is available when one starts Julia without any other flag. Which is special by the fact that one can use packages that are installed in it from other environments.

I have Plots installed there and I don’t find any other alternative reasonable. And Plots only already adds lots of stuff there. Also I have the impression that not recommending installation of packages in the default environment creates artificial constraints for the development of these packages. So for example the developers of BenchmarkTools have to consider that their package is a likely candidate for being in the default environment of everyone in their design choices. That doesn’t seem reasonable to me.

---

<div class="post-metadata">

**Author:** ![mefob](https://avatars.discourse-cdn.com/v4/letter/m/ea5d25/32.png) [@mefob](https://discourse.julialang.org/u/mefob)\
**Post date:** [April 2, 2022, 8:13pm UTC](https://discourse.julialang.org/t/how-to-use-vscode-and-repl-to-write-and-test-a-package/78818/33 "2022-04-02T20:13:38Z")

</div>

Here is an example of a typical workflow that probably many people implement manually. I have not found much documentation describing this flow, are there better solutions? Any suggestions how to approach this more effectively are highly welcome.

Developer Alice creates a package, but neither wants to share her internal development code, nor does she want to pollute her package with the dependencies she uses for development.

Bob is an end-user, who will run the examples provided by Alice. These examples have dependencies beyond those of Alice’s package and Bob would like to have a simple way of instantiating the examples without modifying Alice’s package itself.

Alice is tasked with writing an analysis package MyPkg that she will test using BigSecretDataset. Ultimately, MyPkg will be released to the public, but BigSecretDataset won’t.

Developer Alice starts by creating MyPkg using a modified PkgTemplates. Her package will have tests, example notebooks and a separate project that she will use for development and not share with others.

## This is Alice Developer’s workflow:

Alice creates a package with PkgTemplates, currently the # options are not supported:

```julia-auto
julia> Template(interactive=true)("MyPkg")
Template keywords to customize:
[press: d=done, a=all, n=none]
 > [] user
   [] authors
   [] dir
   [] host
   [] julia
   [] plugins
# create a sub-folder examples in MyPkg package and populate with example usage
   [X] create example folder with new environment 
# create a 2nd project repo that is for the internal use of the developer
   [X] create separate project repo for development

...

```

PkgTemplates creates MyPkg as before, but it also creates

- a project MyPkg\_dev that uses `Revise` and MyPkg. MyPkg\_dev is a separate folder that has its own git repo.
- a subfolder examples in MyPkg that has its own environment, just like the tests folder.

Alice starts writing code in MyPkg/src/MyPkg.jl. Tests are added to MyPkg/test/runtests.jl, just like in any other package. tests also contains the test-only dependencies.

Interactive development takes place in MyPkg\_dev. This is where she will copy BigSecretDataset and put code that is not meant for end users.

VS Code should run any interactive repl in MyPkg\_dev. Probably this would need to be a manual setting in VS Code on Alice’s machine, because MyPkg\_dev is not meant to be shared with the world. If we add a `repl target` option to `Project.toml`, it will point to an empty folder on user Bob’s machine.  
VS Code could recognize a project MyPkg\_dev and ask if this should be used as the development environment.

Alice puts a couple of simplified examples into MyPkg/examples/examples.ipynb.  
Just like MyPkg/test, MyPkg/examples has its own dependencies that do not pollute the package MyPkg.

## This is Bob User’s workflow:

Ultimately, MyPkg is released to the public. Bob can now:

- `pkg> add MyPkg` # adds the package, nothing new
- `pkg> dev MyPkg` # for making changes to dev itself
- `pkg> test MyPkg` # run the tests in the test environment
- `pkg> explore MyPkg` # Doesn’t exist yet: prepare a project with the right dependencies to run the examples in MyPkg

If Bob wants to just use MyPkg, he uses `add`, as he would today. If he wants to create a better version of MyPkg, he uses `dev`. Using `dev` is fine for development, but not for exploring the examples of MyPkg, because then Bob would need to maintain his own version of the package and manually keep track of the upstream changes. Also Bob does not want MyPkg and the examples’ dependencies in his Main environment. This is why the new command `explore` is needed.

`explore` creates a project ~bob/.julia/dev/MyPkg\_explore and copies all of the examples of MyPkg/examples to this folder and adds the example dependencies.  
Bob can now change the examples as he desires and still update MyPkg without merging. He won’t get any updated examples merged into his MyPkg\_explore project, but that is only a minor issue and it makes sense to not overwrite Bob’s example code.

Does this make sense? Is anyone else following a similar workflow by manually creating a 2nd \_dev project for each package they develop and an \_explore project for each package they want to explore?

---

<div class="post-metadata">

**Author:** ![pdeffebach](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pdeffebach/32/10320_2.png) [@pdeffebach](https://discourse.julialang.org/u/pdeffebach)\
**Post date:** [April 4, 2022, 1:36pm UTC](https://discourse.julialang.org/t/how-to-use-vscode-and-repl-to-write-and-test-a-package/78818/34 "2022-04-04T13:36:18Z")

</div>

> [@Nathan\_Boyer](#):
>
> How would I possibly figure out to add that to my `startup.jl` ?

`startup.jl` is mentioned in the docs [here](https://docs.julialang.org/en/v1/manual/getting-started/). You just create a file called `startup.jl` and put it `~/.julia/config`. where `~/.julia` is the same folder you told VS Code to point to when you set up Julia on VS Code.

---

<div class="post-metadata">

**Author:** ![Nathan\_Boyer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nathan_boyer/32/14825_2.png) [@Nathan\_Boyer](https://discourse.julialang.org/u/Nathan_Boyer)\
**Post date:** [April 4, 2022, 3:29pm UTC](https://discourse.julialang.org/t/how-to-use-vscode-and-repl-to-write-and-test-a-package/78818/35 "2022-04-04T15:29:35Z")

</div>

Thanks, but I meant that question colloquially and rhetorically. I was trying to say that no beginner would come up with that function definition on their own. There needs to be an easier way to develop packages without running into dependency and definition issues and without having to define your own custom functions to make development go smoothly.

---

<div class="post-metadata">

**Author:** ![pdeffebach](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pdeffebach/32/10320_2.png) [@pdeffebach](https://discourse.julialang.org/u/pdeffebach)\
**Post date:** [April 4, 2022, 3:32pm UTC](https://discourse.julialang.org/t/how-to-use-vscode-and-repl-to-write-and-test-a-package/78818/36 "2022-04-04T15:32:50Z")

</div>

I agree! But I should also note that it’s not necessary. I developed packages for 2 years without using this function.

There are a lot of lifestyle improvements that are needed for introductory development of packages.

---

<div class="post-metadata">

**Author:** ![Nathan\_Boyer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nathan_boyer/32/14825_2.png) [@Nathan\_Boyer](https://discourse.julialang.org/u/Nathan_Boyer)\
**Post date:** [April 18, 2022, 7:07pm UTC](https://discourse.julialang.org/t/how-to-use-vscode-and-repl-to-write-and-test-a-package/78818/37 "2022-04-18T19:07:20Z")

</div>

I need some more clarification on using a local package and its dependencies in the test environment.

> [@jlperla](#):
>
> To work interactively, given that your package is activated just go `using TestEnv; TestEnv.activate()` when you start up the REPL

> [@jlperla](#):
>
> See [DifferenceEquations.jl/test at main · SciML/DifferenceEquations.jl · GitHub](https://github.com/SciML/DifferenceEquations.jl/tree/main/test) for an example.

```julia
julia> using TestEnv

(@v1.7) pkg> activate MyPackage
  Activating project at `C:\Users\nboyer.AIP\.julia\dev\MyPackage`

julia> TestEnv.activate()
Precompiling project...
  1 dependency successfully precompiled in 1 seconds (3 already precompiled)
"C:\\Users\\nboyer.AIP\\AppData\\Local\\Temp\\jl_nPSgZl\\Project.toml"

julia> using MyPackage

julia> f([3,4])
10.0

julia> norm([3,4])
ERROR: UndefVarError: norm not defined
Stacktrace:
 [1] top-level scope
   @ REPL[49]:1

julia> using LinearAlgebra

julia> norm([3,4])
5.0

(jl_nPSgZl) pkg> status
      Status `C:\Users\nboyer.AIP\AppData\Local\Temp\jl_nPSgZl\Project.toml`
  [4b534a9b] MyPackage v0.1.0 `C:\Users\nboyer.AIP\.julia\dev\MyPackage`
  [37e2e46d] LinearAlgebra `@stdlib/LinearAlgebra`
  [8dfed614] Test `@stdlib/Test`

julia> using Plots
[Info: Precompiling Plots [91a5bcdd-55d7-5caf-9e0b-520d859cae80]

(jl_nPSgZl) pkg> status
      Status `C:\Users\nboyer.AIP\AppData\Local\Temp\jl_nPSgZl\Project.toml`
  [4b534a9b] MyPackage v0.1.0 `C:\Users\nboyer.AIP\.julia\dev\MyPackage`
  [37e2e46d] LinearAlgebra `@stdlib/LinearAlgebra`
  [8dfed614] Test `@stdlib/Test`

julia> plot([1:3],[4:6])
[Info: Precompiling GR_jll [d2c73de3-f751-5644-a686-071e5b155ba9]

```

1. Why does `f` work (using `norm` internally) but `norm` doesn’t until I `using LinearAlgebra`?
2. Why am I allowed to use Plots even though it is only in my global 1.7 environment, not my test environment? I thought `TestEnv` was supposed to restrict this?
3. Why are only some of `DifferenceEquations/Project.toml` dependencies repeated in `DifferenceEquations/test/Project.toml`? Likewise, why are only some DifferenceEquations dependencies `using`-ed in `DifferenceEquations/test/runtests.jl`?
4. Apparently I am not supposed to `] dev .` in my test environment if using the `TestEnv` approach: [link](https://github.com/JuliaTesting/TestEnv.jl/issues/36#issuecomment-998955029)?

> [@ianfiske](#):
>
> I usually advise to create an environment in the package’s `/examples` folder that has `dev .` to use the package and also has `Plots` or `Makie` added.

If I take this approach instead, is compatibility ensured by manually copying the `[compat]` from `MyPackage/Project.toml` to `MyPackage/test/Project.toml` whenever it changes?

**TLDR** : I understand that test-only dependencies can be kept in a separate test environment, but I don’t understand how to call the main package and its dependencies from the test environment (both Project.toml files and `using` statements).

---

<div class="post-metadata">

**Author:** ![Nathan\_Boyer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nathan_boyer/32/14825_2.png) [@Nathan\_Boyer](https://discourse.julialang.org/u/Nathan_Boyer)\
**Post date:** [April 18, 2022, 7:23pm UTC](https://discourse.julialang.org/t/how-to-use-vscode-and-repl-to-write-and-test-a-package/78818/38 "2022-04-18T19:23:28Z")

</div>

Also, the environment seems to not be respecting my `[compat]` entries.  
 ![image](https://global.discourse-cdn.com/julialang/original/3X/7/3/731d804893c9b72ccf473238658002dea132108d.png)

---

<div class="post-metadata">

**Author:** ![jlperla](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlperla/32/34332_2.png) [@jlperla](https://discourse.julialang.org/u/jlperla)\
**Post date:** [April 18, 2022, 7:28pm UTC](https://discourse.julialang.org/t/how-to-use-vscode-and-repl-to-write-and-test-a-package/78818/39 "2022-04-18T19:28:02Z")

</div>

> [@Nathan\_Boyer](#):
>
> Why does `f` work (using `norm` internally) but `norm` doesn’t until I `using LinearAlgebra` ?

Same reason as with normal Julia packages and scoping? You probably had a `using LinearAlgebra` within the package itself. The test environment is orthogonal to that.

> [@Nathan\_Boyer](#):
>
> Why am I allowed to use Plots even though it is only in my global 1.7 environment, not my test environment? I thought `TestEnv` was supposed to restrict this?

Not sure that is an advertised feature. It helps take care of test only dependencies but can’t circumvent environment stacking. So I would add all test only dependencies you need and not rely on stacking…which wouldn’t work with CI (and I don’t think it works with `] test` though could be wrong on that last part.

Regardless, I think the workflow is probably easier

> [@Nathan\_Boyer](#):
>
> Why are only some of `DifferenceEquations/Project.toml` dependencies repeated in `DifferenceEquations/test/Project.toml` ? Likewise, why are only some DifferenceEquations dependencies `using` -ed in `DifferenceEquations/test/runtests.jl` ?

Anything that the tests need to access directly needs to be a test only dependency. There is no automatic exporting from packages of their own dependencies. This is true for all unit tests, not just with TestEnv

> [@Nathan\_Boyer](#):
>
> Apparently I am not supposed to `] dev .` in my test environment if using the `TestEnv` approach: [link](https://github.com/JuliaTesting/TestEnv.jl/issues/36#issuecomment-998955029)?

No, don’t do that. It should all work with only that simple activation workflow I gave. If it doesn’t then chances are that the `] test` wouldn’t either.

Stacked dependencies in your “global” environment could be making things difficult to follow but their is no reason they can’t coexist if you know what you are doing. Personally, I always avoid having globally available non-dev tool dependencies myself because I find it easier to avoid confusing myself and it is easier to have environments completely separated and have manifest snapshots which recreate everything as required.

---

<div class="post-metadata">

**Author:** ![jlperla](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlperla/32/34332_2.png) [@jlperla](https://discourse.julialang.org/u/jlperla)\
**Post date:** [April 18, 2022, 7:30pm UTC](https://discourse.julialang.org/t/how-to-use-vscode-and-repl-to-write-and-test-a-package/78818/40 "2022-04-18T19:30:15Z")

</div>

> [@Nathan\_Boyer](#):
>
> Also, the environment seems to not be respecting my

That doesn’t look like the instantiated test dependency file to me? Though maybe I am missing something. If you do the `TestEnv.activate()` or `] test` it should instantiate an environment which respects bounds you set.

[Previous page](https://discourse.julialang.org/t/how-to-use-vscode-and-repl-to-write-and-test-a-package/78818.md?page=1)

[Next page](https://discourse.julialang.org/t/how-to-use-vscode-and-repl-to-write-and-test-a-package/78818.md?page=3)