Must local projects include packages of interest only to deveolpers?

New to Julia
1

I’m sure I read something about this somewhere in here, just can’t remember where.

I am developing a local package (Python app replacement candidate). I’d like to be able to use BenchmarkTools.jl, AQUA.jl, Debugging.jl, … etc … but the end user environment really doesn’t need any of that. I thought that I had to load the developer-interest packages in the global scope(? not sure of terminology), and the actual packages I need, FFTW.jl, NetCDF.jl, etc. … these get loaded in the local scope.

But when I start the REPL in my project with julia --project=@. and try using Debugging I get an error. Surely I’m doing something wrong but simple to fix?

(Also, how useful are the “tags” on topics? What do those end up being useful for?)

2

You could initially start in a global environment that has those packages you want (environments combine - see Code Loading · The Julia Language). Alternatively, maybe you could put those packages in the [extras] part of your Project.toml to indicate that they are test-specific dependencies (11. API Reference · Pkg.jl).

(Also, how useful are the “tags” on topics? What do those end up being useful for?)

Do you mean e.g. the package tag on your post? They help to label what your post is about, and people can search by tags for example.

1 Like
3

Ok, so when I start Julia with julia --project=@. I am only getting my project environment, and not a stack of the global environment and the local environment? How would I go about setting up a stack of these environments in the REPL, or must this be done in the *.toml files?

4

If you are developing a package, best to actually follow the package docs: 5. Creating Packages · Pkg.jl

So, you put your package code inside a package and then start using it just like any other package. Revise.jl helps tremendously with this, as it makes your changes take effect right when you make them. If you want to benchmark functions or test for type stability or whatever, you can do that at this point. No need to “add them to the package”.

5

Ok - I think I followed the instructions in the creating packages section. Take a specific example. I’d like to use Debugger.jl during development. Must I add this package to my local package in order to use it, or can I somehow use stacked environments, etc., to not have it in the Project.toml file?

6

The classical solution is to add these dev utilities that you often use to your base environment, the one called @v1.9. They will still be available whenever you activate a local project due to stacking

4 Likes
7

Ok - this appears to be user error (not shocking, really). I’m running v1.9.1, but I upgraded manually (surely a bad idea, now that I think about it, but I am somewhat hard-headed). So if I start Julia from the command line with no special directives:

me@skillet:~/Projects/Julia/Stuff$ julia
... elided stuff
Version 1.9.1 (2023-06-07)
(@v1.9) pkg> status
Status `~/.julia/environments/v1.9/Project.toml`
  [6e4b80f9] BenchmarkTools v1.3.2
  [31a5f54b] Debugger v0.7.8
  [9b87118b] PackageCompiler v2.1.7

But perhaps when I run Julia with julia --project=@. it is looking in the environment @v1.9.1 (see edit below) … which doesn’t have any packages in it? Part of the reason I do things manually, is that when I run into weird problems like this, I learn more about how a program works - not to uselessly exercise nice people on the internet, honest.

So, I ran julia --project=@., then:

(@v1.9) pkg> activate @v1.9.1
  Activating new project at `~/.julia/environments/v1.9.1`

(@v1.9.1) pkg> add Debugger
... elided ...

(@v1.9.1) pkg> activate .
  Activating project at `~/Projects/Julia/Stuff`

(Stuff) pkg> ^C

julia> using Debugger

julia>

So in reality, my problem was that I had added these packages to the global environment before I upgraded. I needed to redo this (or use something sane, like juliaup … but I’m not yet sane).

EDIT: when using Julia 1.9.1, the default environment is still @v1.9 (and not v1.9.1). Perhaps it would have been as simple as refreshing the default environment after I did the upgrade? I blew everything away, so it wouldn’t be easy for me to test that again. At any rate, @gdalle’s comment is correct, it should have worked the way I had thought - I just broke it by my awkward manual upgrade.

3 Likes
8

I suggest against @gdalle 's approach. Global env should be kept as minimal as possible. When developing a package, don’t forget the most useful package installation mode, dev. In detail, one first creates a folder wherever one likes. Within it, start Julia REPL and activate the current env via activate .. Then you install your developing package using dev MyPackageToDevelop. You can then install any other package you like in the current env to support your developing workflow.

2 Likes
9

Concur with the suggestion to put stuff like BenchmarkTools into the global env, but other packages like Aqua aren’t really needed there. Instead, they belong to the test environment of your package/project: ]activate test; add Aqua.

2 Likes