Notebook-specific target/Project.toml (similar to test)

General Usage
,
1

Greetings,

I am developing a Julia package in which I have some Jupyter notebooks. Those notebooks use some packages that I do not want to include as general project dependencies (e.g., Plots.jl). However, I do not seem to find a way to manage that.

So far, I have tried the two approaches suggested for handling tests. Given that notebooks are in a notebooks/ folder, I first tried adding a new target to match that, but the Jupyter notebooks do not activate the project. Then, I tried having another Project.toml file inside the notebooks dir, but since the notebook won’t merge automatically with the parent Project.toml file, I don’t even know how to include the parent package as a dependency.

2

This is the way to go. To add the parent directory you use its relative path ... You probably want to use dev rather than add, since you presumably want your notebooks to use the current state of the files rather than a specific commit or release. Thus, the commands will look something like this:

$ cd notebooks

$ julia --project=.

julia> # hit ] to enter pkg mode

(notebooks) pkg> dev ..
   Resolving package versions...
    Updating `~/ParentPackage/notebooks/Project.toml`
  [336d156d] + ParentPackage v0.1.0 `..`
    Updating `~/ParentPackage/notebooks/Manifest.toml`
  [...]

For this to work, the parent directory must contain a package as generated by pkg> generate or PkgTemplates.jl, not just a barebones project environment. Specifically, the parent directory’s Project.toml must contain a name and an UUID.

2 Likes
3

Use the global env for those packages like Plots.jl or setup GitHub - GunnarFarneback/LocalRegistry.jl: Create and maintain local registries for Julia packages. and create a separate package for notebooks.

4

Although I wish I could take the target approach, I’m currently keeping the separate Project.toml file, as suggested by @danielwe.

In case it’s useful for anyone facing the same challenge, I indeed added the parent package as a development dependency, and to access its dependencies I just do using A.B (found out about that here).

5

If you’re actually using B in your notebooks, why not add it explicitly to the notebook env? By relying on using A.B you’re introducing a very tight coupling between the notebooks and implementation details of A, which will be a hassle whenever you want to refactor and reconsider dependencies in A.

The [targets] approach is not expected to work. As far as I understand it currently only supports test.