Hi all,
I have a package that uses Requires
to lazy-load other packages depending on the type of dataset the user is using. As per the Requires
docs for v1.0, all uses of @require
are contained in my packages __init__()
function, and also includes the relevant package UUIDs. I am also using
those packages explicitly in my package runtests.jl file. My question is, how should all this be reflected in the Project.toml file?
Currently, (the dependencies part of) my Project.toml file looks as follows:
[deps]
Distributions = "31c24e10-a181-5473-b8eb-7969acd0382f"
Requires = "ae029012-a4dd-5104-9daa-d747884805df"
StatsBase = "2913bbd2-ae8a-5f71-8c99-4fb6c76f3a91"
[extras]
Random = "9a3f8284-a2c9-5f02-9a11-845980a1fd5c"
Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40"
DataFrames = "a93c6f00-e57d-5684-b7b6-d8193f3e46c0"
TimeSeries = "9e3dc215-6440-5c97-bce1-76c03772f85e"
[targets]
test = ["Random", "Test", "DataFrames", "TimeSeries"]
The two packages that are lazily-loaded via Requires
are DataFrames
and TimeSeries
. Does this look right? It seems to work, but perhaps I’m committing some cardinal sin by only including entries for these packages under extras
and not under deps
. Maybe they should have entries under both headings? But will that force users to have those packages installed if they want to use my package?
Any advice would be much appreciated.
Cheers,
Colin
Looks perfectly fine to me.
Yea, what you put into [deps]
are dependencies that will be installed when installing your package, so if you want e.g. DataFrames
as a optional dependency then that should not be listed there.
1 Like
Thanks for responding. That is very helpful. I might open a PR on the docs at Requires.jl with some information from your response, so just to be sure I understand correctly:
When lazy-loading a package via @require
, it is not necessary to include any information on the lazily loaded package in your Project.toml file, since the package name and UUID are already included as part of the @require
call in your code. The only reason for including a lazily-loaded package in Project.toml is if a) It is used in runtests.jl, in which case you include it under the [extras]
heading, or b) you want to force your users to install it when installing your own package for some reason, in which case you include it under [deps]
.
Thanks again,
Colin
But if you have it as a regular dependency there is not really a reason to use Requires
at all, is there?
A “dependency” warning pops up when you don’t put the @require
’d packages under the [deps]
portion of the Project.toml. The warning show up when you import the @require
d package after you’ve imported the main package that has the @require
s.
Here’s a toy example to illustrate what I’m seeing:
RequiresDebugging.jl
:
module RequiresDebugging
using Requires
function __init__()
@require Distributions = "31c24e10-a181-5473-b8eb-7969acd0382f" begin
using Distributions
println(rand(Normal(5,1)))
end
end
end # module
Project.toml
:
name = "RequiresDebugging"
uuid = "596e472d-9fbf-4322-a790-b7559c9241c7"
version = "0.1.0"
[deps]
Requires = "ae029012-a4dd-5104-9daa-d747884805df"
Testing:
julia> using RequiresDebugging
julia> using Distributions
┌ Warning: Package RequiresDebugging does not have Distributions in its dependencies:
│ - If you have RequiresDebugging checked out for development and have
│ added Distributions as a dependency but haven't updated your primary
│ environment's manifest file, try `Pkg.resolve()`.
│ - Otherwise you may need to report an issue with RequiresDebugging
â”” Loading Distributions into RequiresDebugging from project dependency, future warnings for RequiresDebugging are suppressed.
5.9298179872536965
To @colintbowers’s original point, it seems counterintuitive to have to put the @require
d optional packages in the Project.toml if we don’t want them installed when someone adds the package itself. Of course, it’s simply a warning—but this can cause loads of confusion (see https://github.com/JuliaGraphics/Luxor.jl/issues/199).
In this example, if we add Distributions
to the [deps]
section, this warning disappears.
This is related to https://github.com/JuliaPackaging/Requires.jl/issues/65 as well, but that thread discusses a custom “submodule” instead of another installed package.
Any tips to mitigate this, or is this something fundamental to Requires.jl?
1 Like