# Workflow for development packages
**URL:** https://discourse.julialang.org/t/workflow-for-development-packages/123102
**Category:** General Usage
**Tags:** question, environment
**Created:** [November 26, 2024, 1:13pm UTC](https://discourse.julialang.org/t/workflow-for-development-packages/123102 "2024-11-26T13:13:41Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [November 26, 2024, 1:13pm UTC](https://discourse.julialang.org/t/workflow-for-development-packages/123102/1 "2024-11-26T13:13:41Z")
There are some packages I mostly use while _developing some package_. These include, for example, JET.jl & Cthulhu.jl when I am debugging, a bunch of `<: AbstractArray` implementations (StaticArrays.jl, etc) when I want to test how generic and type stable an API is, etc.
I don’t want to add a bunch of packages to the “global” environment `@v#.#`. Obviously, I don’t want to add them to the package I am working on.
So what is the best solution? I thought of collecting a cluster of packages in a named environment that I put in the depot path, eg `@debug` for the debug tools. This I could then insert to `LOAD_PATH` on demand.
But I can see several practical issues:
1. not all Julia versions I am using would support the latest version of these tools. In fact, JET is closely tied to a specific Julia version.
2. I am not aware of tooling to manage `LOAD_PATH`. Of course I can use generic mutable vector functions, but a text-based gui would be nicer. Does that exist?
How do users manage this problem, ie keep an environment for development packages while keeping other environments clean?
---
### Author:  [@SteffenPL](https://discourse.julialang.org/u/SteffenPL)
#### Post date: [November 26, 2024, 1:20pm UTC](https://discourse.julialang.org/t/workflow-for-development-packages/123102/2 "2024-11-26T13:20:43Z")
Would ShareAdd.jl work for your setting?
---
### Author:  [@gdalle](https://discourse.julialang.org/u/gdalle)
#### Post date: [November 26, 2024, 1:28pm UTC](https://discourse.julialang.org/t/workflow-for-development-packages/123102/3 "2024-11-26T13:28:19Z")
> [@Tamas\_Papp](#):
>
> I don’t want to add a bunch of packages to the “global” environment `@v#.#`.
For lightweight, generic tools like JET.jl and Cthulhu.jl, the global environment seems like a good choice. For other things like StaticArrays.jl, a shared environment like `@debug` seems more appropriate. At least that’s how I usually do it.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [December 2, 2024, 10:07am UTC](https://discourse.julialang.org/t/workflow-for-development-packages/123102/4 "2024-12-02T10:07:53Z")
@SteffenPL: Yes, ShareAdd is kind of like what I am looking for. Thanks!
---
### Author:  [@lmiq](https://discourse.julialang.org/u/lmiq)
#### Post date: [December 2, 2024, 10:25am UTC](https://discourse.julialang.org/t/workflow-for-development-packages/123102/5 "2024-12-02T10:25:35Z")
Just for the records, if those packages are part of the testing environment, TestEnv.jl is a useful tool. I have it in the global environment and find myself using it quite often now.
---
### Author:  [@aplavin](https://discourse.julialang.org/u/aplavin)
#### Post date: [December 2, 2024, 10:46am UTC](https://discourse.julialang.org/t/workflow-for-development-packages/123102/6 "2024-12-02T10:46:49Z")
> [@Tamas\_Papp](#):
>
> a bunch of `<: AbstractArray` implementations ([StaticArrays.jl](https://juliahub.com/ui/Packages/General/StaticArrays), etc) when I want to test how generic and type stable an API is
Sounds like you should add them to the test env,
```julia
] activate test
] add StaticArrays
```
then just use them in package tests, and use TestEnv as @lmiq suggests to make them available in the REPL.
Other packages that are not needed for your package tests – temp envs just work in Julia, do `using Cthulhu` and Julia suggests installing it. For even more convenience, try BasicAutolods.jl – then, typing stuff like `@descend_code_warntype ...` would automatically ask if you want to install Cthulhu (can do it in a temp env).
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [December 2, 2024, 1:18pm UTC](https://discourse.julialang.org/t/workflow-for-development-packages/123102/7 "2024-12-02T13:18:16Z")
> [@lmiq](#):
>
> if those packages are part of the testing environment
Yes, TestEnv.jl is great, but my use case in the OP is for packages that are _not_ in the test environment — debugging and exploratory use.
> [@aplavin](#):
>
> do `using Cthulhu` and Julia suggests installing it
Certainly, but that comes with a time delay (even if the package itself is cached, the package manager may check the registry for the latest version).
---
### Author:  [@aplavin](https://discourse.julialang.org/u/aplavin)
#### Post date: [December 2, 2024, 3:23pm UTC](https://discourse.julialang.org/t/workflow-for-development-packages/123102/8 "2024-12-02T15:23:21Z")
> [@Tamas\_Papp](#):
>
> even if the package itself is cached, the package manager may check the registry for the latest version
Add
```julia
import Pkg
Pkg.UPDATED_REGISTRY_THIS_SESSION[] = true
```
to your startup.jl. That’s the setting created exactly to avoid all these implicit registry updates.