I’m currently developing a package (unreleased). I added it to my working environment by giving Pkg the URL to my Github repository
This package uses some the standard libraries such as Dates. So at the top of my module file I have a line:
module Foo
using Dates
But every time I load the package I get the following warning:
**julia>** using Foo
**[ Info:** Precompiling Foo [47358f48-d834-4249-91f5-f6185eb3d540]
**┌ Warning:** Package Foo does not have Dates in its dependencies:
**│** - If you have Foo checked out for development and have
**│** added Dates 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 Foo
**└** Loading Dates into Foo from project dependency, future warnings for Foo are suppressed.
This warning does not make sense to me. It’s part of the standard library and so isn’t listed in Project.toml or Manifest.toml.
I even tried following the steps recommended in the warning and this is what I got:
**julia>** Pkg.resolve()
**No Changes** to `~/Foo_dev/Project.toml`
**No Changes** to `~/Foo_dev/Manifest.toml`
And no change to the warnings I get when loading the package.
Next I tried activating the package’s own environment and adding Dates there. That was successful in the sense that Dates was added to the packages Project.toml which I’m not sure this is a good idea because now there’s an implicit dependency on a specific version of Julia, right? But in any case it didn’t make the warning go away.
This is very strange to me and I don’t understand what Julia is complaining about. Can anyone help? I’m most concerned that if I release this package someday I don’t want users to be seeing this message.
The only thing “special” about stdlibs is that they’re shipped with julia. You still have to e.g. ] add Dates to make the resolver aware that you’re using it. This information is needed when e.g. compiling your code to a static library or (in the future) for tree shaking.
Well you always have an explicit dependency on the version of julia you’re running due to the features of a julia version you’re using that aren’t in precious versions. If you plan to release & register it to the General registry, you’ll not only have to add compatibility bounds for your package dependencies, but also for the julia version your code is compatible with.
Have you bumped the version of your package after adding the dependency? If you haven’t, this is most likely why. If there is no new version, how should julia know that anything has changed?
I don’t really understand how this part works so I’m confused. It’ll know that things have changed because it’s reading all the files fresh every time I load it? Julia is precompiling every time I load, so if Julia is assuming that the code has changed, why shouldn’t it assume that Project.toml has changed as well?
In any case, I’m new to package development so how would I go about bumping the version? Change the version number in the Project.toml? Or the UUID? Or both? And is there a way to change this short of me editing Project.toml by hand?
I think it is after this step you should run Pkg.resolve() in your main environment. Because that environment still has added the old version and resolved the old dependencies of your package, and sees that something is missing. You have now fixed it, but the main environments manifest is not updated so it doesn’t know that.
Because dependency resolution should work without having to parse, compile & potentially run (considering __init__ exists) your code! If the dependency on Dates is not recorded in Project.toml, the only way to find out that it is a dependency would be to run your code, which is really not ideal.
Having this based on a version number also allows finer granularity than just “there has been a change”, e.g. for bug patches (x.y.1 -> x.y.2) compared to new features (x.1.z -> x.2.0) or backwards-incompatible (so called “breaking” changes, 1.y.z -> 2.0.0). Some users of your package may be fine with only bug fixes, some may be willing to have new features (and thus possibly faster code/new dependencies) while others may want to live on the bleeding edge and fix potential breakages due to new major versions.
Only the version number (and that iirc only by hand at the moment. It’s always at the very top of the file though, so you won’t have to search far for it). The UUID (as the name implies, Universally Unique Identifier) is used instead of the package name for identifying your package, as with just the package name there may be undesirable & unresolvable name conflicts (on a conflict, Pkg asks you which version you prefer).
You should be able to add any standard library as a project dependency just by doing add Dates for example. If that doesn’t work then something is quite odd about your setup. Have you changed the load path perhaps?