Warning: Package SoilWater_ToolBox does not have Configurations in its dependencies:

Tooling Package Management
1

Halllo,

I am creating my first Package which is exciting but also challenging of the large software SoilWater-ToolBox

I believe that the package works locally, but I am getting the following warning Package SoilWater_ToolBox does not have Configurations in its dependencies which might be the cause of publishing the package.

Many thanks for informing me if I should I take action on the warning or forget it?

**strong text**
```julia> using SoilWater_ToolBox
[ Info: Precompiling SoilWater_ToolBox [374a444c-c624-4b44-9de1-37c0fe7c6d41]
┌ Warning: Package SoilWater_ToolBox does not have Configurations in its dependencies:
│ - If you have SoilWater_ToolBox checked out for development and have
│   added Configurations 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 SoilWater_ToolBox
â”” Loading Configurations into SoilWater_ToolBox from project dependency, future warnings for SoilWater_ToolBox are suppressed.
2

“add” the package, as if you were installing it, when the environment of your package is activated:

julia> ] activate SoilWater_ToolBox
(SoilWater_ToolBox) pkg> add Configurations

that will add the Configurations package to the dependency list in “Project.toml”.

1 Like
3

@lmiq thanks for kindly answering my query, I was not aware that you need to add the external Packages again separately as they are not looked up automatically from the main package Julia.

A small question can we add [compat] automatically

https://pkgdocs.julialang.org/v1/toml-files/

The [compat] section
Compatibility constraints for the dependencies listed under [deps] can be listed in the [compat] section. Example:

[deps]
Example = "7876af07-990d-54b4-ab0e-23690620f79a"

[compat]
Example = "1.2"
The Compatibility section describes the different possible compatibility constraints in detail. It is also possible to list constraints on julia itself, although julia is not listed as a dependency in the [deps] section:

[compat]
julia = "1.1"
4

There is “CompatHelper” that is a GitHub action that helps with compat entries. But I particularly do not like it much, and mostly add an manage compat entries manually. I don’t know of other alternative.

(It is not that they are not looked up, is that adding them to the environment is what makes that specific package/environment dependent on them, it won’t install again or make new copies of the packages. You can or course still use other packages)

5

@lmiq a great thanks than I will than add the [compact] manually which my understanding is a prerequisite for making a package. But sometimes the version of the installed package is not indicated in Manifest.toml so therefor I put version 0.1.0

So each time I modify the code I will need to build the package manually. Is there a way to build the package automatically after VSCODE detects a change in the code?

6

There are some packages, which are shipped with Julia (LinearAlgebra, Printf, etc) that do not need compat entries.

Using 0.1.0 won’t work, that will restrict completely the version to that version. What I do (and not necessarilty what I recommend, because I find it still somewhat patchy) is:

  1. Check the version installed (probably looking to Manifest is the same), here I show examples with two packages, one with a version greater than 1, the other with a version 0.X:
(@v1.6) pkg> status StaticArrays
      Status `~/.julia/environments/v1.6/Project.toml`
  [90137ffa] StaticArrays v1.2.1

(@v1.6) pkg> status Parameters
      Status `~/.julia/environments/v1.6/Project.toml`
  [d96e819e] Parameters v0.12.2
  1. I add these entries:
[compat]
StaticArrays = "1" 
Parameters = "0.12"

This is because, for 0.X versions, the convention is that changing the second number (0.12 to 0.13, for example), is a breaking change in the interface. For 1.X versions, breaking changes are in the first number 1.X to 2.X for example.

The third number for 0.X.Y versions may add features and bug fixes, you may have to check if you are using some recent feature and restrict the version even further to the last digit. The same for 1.X.Y versions, X may be carry the addition of a new feature, which you may require for your package.

What is somewhat annoying is that if you use 1.3, for example, your package will not run with 1.4. I could not figure out exactly how to allow 1.3+ versions (anyone?), I always got warning of failed automerging, I think. CompatHelper “helps” by pushing commits to the repo that add lists like “1.3 1.4 1.5 1.6” every time a new version of a package is released. But it gets disabled after some time, and polutes the repo commits, such that I finally l decided to disable it.

Not sure what you mean here. Are you using Revise?

7

Thanks you answered beautifully my questions. I am now struggling to publish the SoilWater_ToolBox package.

8

Well, I have been there and made some notes: Create new package · JuliaNotes.jl

And: Publish Docs · JuliaNotes.jl

1 Like
9

Thanks @lmiq for the very useful documentation :grinning_face_with_smiling_eyes:. Just arrived from winter holiday in New Zealand :cold_face:. I wished I saw your documents before registration the package which has some issues. Once the registration works I will create a release and will be in contact with you for some further questions.

My issues are as follow:
JuliaRegistration

Kind regards,
Joseph

2 Likes