Correct way to prepare dependencies of a julia project for publishing?

I come from python where each environment has an independent list of packages. This simplifies publishing the project to github because you can just install from a requirements.txt file.

According to this Q&A Understanding environments and projects, Julia has a stack of environments from which it will pull packages. How do I achieve the same behavior when I publish my project to github (i.e. create a list of packages the project depends on so end-users can clone the repo and just run “install requirements.txt”? The problem is given Julia has an environment stack it pulls packages from when you do “using X”, Project.toml for the current project doesn’t list all the packages you’re actually using.

2 Likes

Right, that’s what the Manifest.toml file is for.

It seems you’re after this info (more or less): Frequently Asked Questions · The Julia Language

If you want to reproduce not only the set of packages, but also the versions you were using in the previous Julia version, you should also copy the Manifest.toml file before running the Pkg command instantiate.

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

3 Likes

As I understand it, the stack of environments is only there so that you can use tooling (such as Revise, Debugger…) in an interactive context while developing: these package introducing tools can be installed once and for all in the default environment (on top of which the active project’s environment is stacked).
The packages that are actually dependencies of your project (i.e. packages for which there are using or import statements in your project code) should all be listed in the project’s environment.

This list of (direct) dependencies is stored in the Project.toml file, which you can update via the add/rm commands of the package manager.

If you forget to explicitly list a dependency, things might still work (because of stacked environments, or because it’s a standard library), but you’ll still get a warning during tests, and also when you try using your package and it gets precompiled. This helps maintaining Project.toml up-to-date.

julia> using Foo
[ Info: Precompiling Foo [e0958bea-714e-463a-a34c-e3fc1ef883d0]
┌ Warning: Package Foo does not have LinearAlgebra in its dependencies:
│ - If you have Foo checked out for development and have
│   added LinearAlgebra 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 LinearAlgebra into Foo from project dependency, future warnings for Foo are suppressed.

In order to install the dependencies on a new system, your users (or your future self) only need to run the package manager instantiate command. As said in previous posts, if you ship the Manifest.toml file alongside your sources, the full environment will even get entirely reproduced (i.e. the full list of direct and indirect dependencies, each in their own specific version).

4 Likes

This seems to work correctly for packages, but what about the version of Julia itself ?

1 Like

Yes, your’re right to point this out: the contents of the Manifest depend on the version of Julia itself; your users need to use the same version if they want to reproduce everything.

Is’nt there a plan to modify Project.toml to potentially include julia version in future releases ? I thought I saw something like that in a PR or in release notes.

I think as of Julia 1.7, this should be under [compat] in Project.toml.

Haa i found it:

Moreover, this was backported to 1.6.2 LTS accoridng to the github discussion linked.

So NVM, sharing your manifest is enough for total reproducibility starting from 1.6.2

1 Like

The version of Julia is included in the generated Manifest.toml (not sure since when). So you can know which version to install in order to use a particular Manifest, but the package manager does not install Julia for you (that’s how I understood your first question)

You should include compatibility bounds for all dependencies of your project (including Julia itself) in the Project.toml file. AFAIU These will be used to resolve a consistent environment when needed (i.e. when you do not already have an adequate Manifest.toml)

Yes changing julia version is not automatic :wink: Although there is GitHub - LilithHafner/UpdateJulia.jl: Simple cross platform Julia installer

1 Like