Integrating Plots into a package

General Usage
,
1

Hi everyone,

I recently started with the development of ExactFieldSolutions.
The package aims at providing full-field exact solutions for various PDEs, which can then be used for verifying the accuracy of numerical solutions.

The package has Plots.jl as dependency, as it is being use in part of the scripts for examples of visualisation (in folder visualisations) and examples of convergence tests (in folder benchmarks) .

I had the request to make Plots.jl an extension. It makes sense as common usage would not require any visualisation. Users may not want to load plots at all (running on a cluster) or may rely on other visualisations tools that exports visualisation functions with similar name.

For this, Iā€™ve moved the benchmarks and visualisations folder into an ext folder. Then, Project.toml was edited that way. The hope is that if the user employs any of the scripts located in any of these 2 folders, then Plots.jl would be installed. Unfortunately, this create problems, running a script from folder visualisation complains about Plots.jl not being installed. On the other hand, running a script from folder benchmarks attempts to install Plots but then complains about GR_jllā€¦

What would be the best way to handle this kind of situation? Is there something obviously wrong?

Many thanks in advance for your advices!

2

Extensions donā€™t sound like the right tool for this problem at all. The usual approach would be to have a separate environment for the examples, where both the ExactFieldSolutions and Plots packages would be available.

5 Likes
3

Thanks for the suggestion. I didnā€™t know that a package could host several environments internally. This could be a good solution. I will give it a try!

4

I use the test environment for this purpose, but there might be better ways.

If you want to activate it, use:

using TestEnv; TestEnv.activate()

In my examples that need plotting I have the code:

  using Pkg
  if ! ("ControlPlots" āˆˆ keys(Pkg.project().dependencies))
      using TestEnv; TestEnv.activate()
  end
  using ControlPlots

and in Project.toml I have:

[extras]
ControlPlots = "23c2ee80-7a9e-4350-b264-8e670f12517c"
Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40"

[targets]
test = ["Test", "ControlPlots"]
5

Can we think of a title that will make this answer more searchable in the future? Say, ā€œIntegrating Plots into a Packageā€ or something even better?

1 Like
6

Maybe ā€œWhatā€™s the best way to demonstrate my package using Plots.jl?ā€?

7

Well, in fact the problem would rather be: how to demonstrate a package, when demonstration requires dependencies that are not essential to the core of a package. I took Plots as an example but other packages may be concerned. I have just tested the solution of @GunnarFarneback and this works. It allowed to remove Plots, Symbolics and SparseDiffTools from the environment of the core package. Now I have to see how nice it is in practice for further developing the package (i.e. I like visualising when I add new solution, so this may require switching environments back and forth). Thanks a lot for the many suggestions!

8

For the future you probably want to check out the Pkg workspace feature, but Iā€™m not sure whether this will be available in Julia 1.11 or 1.12.

2 Likes
9

thanks again everyone for your help. Iā€™ve tagged the first answer of @GunnarFarneback as the solution - ExactFieldSolutions.jl now uses this approach. I will definitely try out the workspace feature in the future, this seems indeed ideally designed.

1 Like